Date: Tue, 6 May 2003 23:44:01 +0400 (MSD) From: Igor Sysoev <is@rambler-co.ru> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) Message-ID: <Pine.BSF.4.21.0305062342570.68150-100000@is> In-Reply-To: <3EB7D23D.FD5E4191@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 May 2003, Terry Lambert wrote: >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. I do not see any difference in a stack glue when rfork() called with RFTHREAD and without it. >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. What is difference of these stack glues ? >> > > 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. I will sendpr but not to the linuxthreads maintainer. linuxthreads port does not use rfork_thread(3). It uses its own similar rfork(2) wrapper to set up the stack and this wrapper handles errors correctly. >> > > 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. It's recent changes 1.182 in 5.0 and 1.72.2.12 in 4.8 in kern_fork.c. Now rfork() requires RFTHREAD to be set if RFPROC is set. >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. Well, but I think this change should be documented. Right now rfork(RFPROC|RFMEM) returns EINVAL and rfork_thread(2) causes segmentation fault because it does not handle errors correctly. >> > 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 Yes, I belive it, rfork(RFPROC|RFMEM) runs on FreeBSD-4.3. >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. RFTHREAD got to be required recently. Igor Sysoev http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0305062342570.68150-100000>