Subject: Re: Real vfork() (was: third results)
To: None <thorpej@nas.nasa.gov>
From: John S. Dyson <dyson@freebsd.org>
List: tech-kern
Date: 04/16/1998 14:19:04
Jason Thorpe said:
> On Wed, 15 Apr 1998 22:10:18 -0700 (PDT) 
>  tooleym@douglas.bc.ca wrote:
> 
>  > For god's sake! Someone post some concrete, verifiable, non-arguable
>  > message and end it! I beg you!
> 
> If you insist!  :-)
> 
> Here are the facts:
> 
> 	* NetBSD's new vfork(2) implements the pre-4.4BSD semantics.
> 
> 	* The vmspace-sharing piece is faster than even the best COW
> 	  algorithm.
> 
> 	* The original pre-4.4BSD vfork(2) semantics are now specified
> 	  in XPG4.2.  This means that new systems that want to carry the
> 	  UNIX(tm) trademark must implement the address space-sharing
> 	  semantics.  I.e. the interface is compatible with the rest of
> 	  the industry.
> 
> 	* There is a noticeable performance improvement, especially
> 	  for large processes, e.g. make(1) bulding the C library or
> 	  kernel.
> 
> 	* The change was discussed at length with members of Core and
> 	  the developer of NetBSD's new VM system (UVM), Chuck Cranor.
> 
> Given these, plus the fact that I wrote NetBSD's new vfork(2) implementation,
> it's not likely that I'm going to be swayed back to a 4.4BSD vfork(2).
> 
Another reason is that FreeBSD supports vfork, and applications are
likely going to be written to support the semantics.  I will also be
looking at spawn, but with vfork taking approx 50usecs, it is harder to
justify.

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.