From owner-freebsd-hackers Thu Jan 30 19:35:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27087 for hackers-outgoing; Thu, 30 Jan 1997 19:35:18 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27081 for ; Thu, 30 Jan 1997 19:35:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA01399; Thu, 30 Jan 1997 20:34:09 -0700 From: Terry Lambert Message-Id: <199701310334.UAA01399@phaeton.artisoft.com> Subject: Re: Using rfork() / threads To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 20:34:09 -0700 (MST) Cc: terry@lambert.org, cracauer@wavehh.hanse.de, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org In-Reply-To: <199701310201.SAA00278@bubba.whistle.com> from "Archie Cobbs" at Jan 30, 97 06:01:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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.