Date: Fri, 31 Jan 1997 13:45:57 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: Archie Cobbs <archie@whistle.com>, cracauer@wavehh.hanse.de, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads Message-ID: <Pine.SV4.3.95.970131133808.4331A-100000@parkplace.cet.co.jp> In-Reply-To: <199701310334.UAA01399@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Jan 1997, Terry Lambert wrote: > > > The per process open file table points to the same location, for one > > > (that's actually a biggie). If I open a file in one process, it is > > > open for both processes. If I close it, it's closed. There is one > > > fd offset associated with the object -- if one process writes it, > > > the offset is advanced, and if the other writes it, it's advanced > > > again. There is a potential race as to who gets to do the write. > > > > What about the heap... is it shared? What about shared libraries? > > I assume stack regions are not shared... > > Stack is not shared. I believe mmap'ed memory regions remain shared. > I believe heap data is shared, including libs... if this isn't true, > then we don't need libc_r for a kernel threads environment. But it > would also mean that context sharing needs to use data in shared > memory (making heap process ["thread"] local to each process). If > this is true, then sfork() is like Sequent's vfork(). I thought > that it wasn't true, though, and that's why the call name was changed. > > I really haven't played with sfork() much, recently... you should > contact the author. Or look at the man pages and source. man rfork See /usr/src/sys/kern/kern_fork.c and /usr/include/sys/unistd.h. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970131133808.4331A-100000>