Date: Thu, 30 Jan 1997 20:34:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: archie@whistle.com (Archie Cobbs) Cc: terry@lambert.org, cracauer@wavehh.hanse.de, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads Message-ID: <199701310334.UAA01399@phaeton.artisoft.com> In-Reply-To: <199701310201.SAA00278@bubba.whistle.com> from "Archie Cobbs" at Jan 30, 97 06:01:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701310334.UAA01399>