From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:19:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50E3C37B401 for ; Tue, 6 May 2003 08:19:41 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB2E43FCB for ; Tue, 6 May 2003 08:19:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19D4EA-00052f-00; Tue, 06 May 2003 08:19:35 -0700 Message-ID: <3EB7D23D.FD5E4191@mindspring.com> Date: Tue, 06 May 2003 08:18:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43780838b73a9dade91a8d1173f4a58de93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:19:41 -0000 Igor Sysoev wrote: > On Mon, 5 May 2003, Terry Lambert wrote: > > Igor Sysoev wrote: > > > On Mon, 5 May 2003, Terry Lambert wrote: > > > What is stack glue ? > > > > See the code in fork1() in /sys/kern/kern_fork.c. > > I do not see any stack manipulation in kern_fork.c except the creating > alternate kstack for KSE thread in 5.0. And rfork(2) can not create > such stack - it passes 0 to fork1(). You misunderstand. After the rfork() returns, there is different stack glue required to implement "a threads library" when you use RFTHREAD than when you don't use RFTHREAD. And I *know* it can't create the stack: you have to do that in user space with assembly language glue you provide. In other words, it's working without RFTHREAD, you're just using the wrong stack glue in user space. > In 4.x there's no stack code at all. That's because there's no thread library that uses rfork(), apart from the linuxthreads port. > > > I use rfork_thread(3) wrapper that allows to setup another stack for > > > rfork()ed process. > > By the way I found the bug in x86 rfork_thread(3)'s error handling: > > --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 > +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 > @@ -108,5 +108,8 @@ > * Branch here if the thread creation fails: > */ > 2: > + popl %esi > + movl %ebp, %esp > + popl %ebp > PIC_PROLOGUE > jmp PIC_PLT(HIDENAME(cerror)) sendpr the fix to the linuxthreads maintainer, please. > > > What RFTHREAD flag does ? > > > > See the code. It basically sets up for kernel threading, rather > > than merely for processes sharing the same address space and/or > > file descriptor table and/or heap, which is what rfork was > > intended to be able to do. It also ensures propagation of any > > SIGKILL to all peers, so they die all at once, in exit1() in > > /sys/kern/kern_exit.c. > > It seems that the single purpose of the RFTHREAD flag is to kill peers > when the leader got SIGKILL. > And in 4.8-STABLE and 5.0-CURRENT (after 5.0-RELEASE) the leader also > holds P_ADVLOCK flag. Yes, that's just for cleaning up advisory locks, which mostly no one uses in threads applications, since they can cause one thread to deadlock another. > > > By the way linuxthreads port always uses RFTHREAD flag. > > > > They don't know any other way than the moral equivalent of > > the Linux "clone" system call, so that's what they use; it's > > technically not necessary. See also the source code in the > > Now it's necessary. Otherwise rfork() returns EINVAL. It only does that if at least one of a set of flags is not set; I don't see where you think EINVAL is coming from. But in any case, if RFTHREAD makes something work for you, then by all means use it. It should not be implied, and it should not be required by documentation, since, as you noticed reading the code, all it does is associate sibling threads under a parent for killing and advisory locking. > > directory /usr/src/lib/libpthread, which doesn't use rfork() > > at all. > > I know it. My point was that the only code that uses it without RFTHREAD successfully is probably about two years old, and was never committed to the tree as part of a threads library. You would need to check the mailing list archives for "Jason Evans" and "John Dyson", in combination with "rfork", to find the code that "fixes" needing RFTHREAD. -- Terry