From owner-freebsd-hackers Thu Jan 30 20:46:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA01004 for hackers-outgoing; Thu, 30 Jan 1997 20:46:17 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00999 for ; Thu, 30 Jan 1997 20:46:13 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id EAA04600; Fri, 31 Jan 1997 04:45:57 GMT Date: Fri, 31 Jan 1997 13:45:57 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Archie Cobbs , cracauer@wavehh.hanse.de, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: <199701310334.UAA01399@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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