Date: Thu, 26 Oct 1995 08:15:08 -0400 (EDT) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: Terry Lambert <terry@lambert.org> Cc: deraadt@theos.com, hackers@FreeBSD.org Subject: Re: anatomy of rfork, part 2: fork code Message-ID: <Pine.SUN.3.91.951026081029.7368A-100000@terra> In-Reply-To: <199510252102.OAA19472@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.951026081029.7368A-100000>