Date: Thu, 20 Aug 1998 00:19:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: hackers@FreeBSD.ORG Subject: Re: sfork()? Message-ID: <199808200019.RAA29165@usr05.primenet.com> In-Reply-To: <Pine.SUN.3.91.980819124919.12449D-100000@terra> from "Ron G. Minnich" at Aug 19, 98 12:57:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > yes, evil evil evil man pages. :) > > and, actually John Dyson told me about rfork, i thought it was "fixed" > > though. > > OK, now I am lost. I just looked at -current kernel source and see that > freebsd rfork does not split the stack. What's funny is my old ca. 1994 > rfork for freebsd does split the stack. In fact I now wonder if my design > was not somewhat nicer, since it does split the stack and requires no > user-land assembly code. I'm still running 16 nodes with that old OS and > old rfork and I'm going to not have fun upgrading them with -current > rfork ... > > now what? How did you split the stack? Did you put it in thread local storage? Did you limit the size it could grow to? Either would be bad... The code Loqui posted has a problem: there are no guard pages on the stack. The correct approach is probably to mmap() anonymous pages from /dev/zero instead to ensure that there are guard pages, and to install a SIGSEGV handler and leave a large enough gap that you can auto-grow the stack in the trap handler using a "pager" thread (or doing it in the handler, which I dislike). The problem with a split stack that is not based on heap memory allocation and/or non-anonymous mappings and/or a copied rather than shared page table is kernel threads. When I instance objects which I want to hand over to another thread, I should not have to copy the object between threads. The need to copy the object (via CreateFreeThreadedMarshaller(WIN32)) between threads in NT and Windows 95 was one of the biggest design blunders in Microsoft history, IMO. John's design avoids this, but has the unfortunate problem that the stack management is left up to user space. If I understand the shared page map correctly, mapping pages into one thread should map them into all threads; this should be sufficient for sbrk() and growable stacks (instead of the default 8k stacks pthreads tries to stick you with). The key here is what happens in an rfork() child when memory is mapped into the parent address space; if it does not immediately become available in the child address space, then you have repeated Microsoft's blunder. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808200019.RAA29165>