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.