Date: Tue, 06 May 2003 08:18:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) Message-ID: <3EB7D23D.FD5E4191@mindspring.com> References: <Pine.BSF.4.21.0305061751340.64470-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB7D23D.FD5E4191>