From owner-freebsd-hackers Thu Oct 26 05:16:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA03846 for hackers-outgoing; Thu, 26 Oct 1995 05:16:47 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA03840 for ; Thu, 26 Oct 1995 05:16:44 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA07403; Thu, 26 Oct 1995 08:15:09 -0400 Date: Thu, 26 Oct 1995 08:15:08 -0400 (EDT) From: "Ron G. Minnich" To: Terry Lambert cc: deraadt@theos.com, hackers@FreeBSD.org Subject: Re: anatomy of rfork, part 2: fork code In-Reply-To: <199510252102.OAA19472@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk > One presumes exit(2) knows how to clean this up? (in reference to the shared fd tables) exit() cleans it up quite nicely. It decrements the reference count and if it goes to 0 deletes the table. No big deal. I did not do any real work for fd table sharing, all the needed pieces were there: i just used them. > I implemented fd table sharing in UnixWare 2.0 using something similar > to the following in the user process: > ... > Which does the same thing without requiring the introduction of an > additional system call interface or fork abstraction. rfork is much more than just fd table sharing. Check previous messages. Also, fork is a subset of rfork, so all you really have to do is implement rfork and fork comes for free. Net change in number of system calls: zero. Your fd table sharing via /proc is interesting, but it adds more state to the process which the kernel has to track and act on. Also, user code needs to track and act on that state too, since it may or may not want to have the same behaviour on each fork. I prefer the rfork approach. ron