Jason Thorpe writes:

>Uh, it's a significant performance boost even on modern hardware for 
>the types of applications where it is intended to be used.

What are these applications?  I can't right now think of any which
produce a steady stream of fork/exec, enough to satisfy the CPU with
only these operations...  Even huge, make-directed build jobs spend
almost all of their time in compilers, or on disk i/o, etc.

Is vfork mandated by any standards?  If not, it's my belief that it
should go; maybe kept in a compatibility library for legacy
applications, using ordinary fork/exec.  IMHO a small performance
improvement doesn't warrant adding elements to the system API.  I don't
know the original intentions but I'd guess that, when vfork() was
introduced, it was meant to be a temporary hack, a workaround around
the CPU bug, and not to stay forever.  It is ugly, it is inelegant, it
doesn't fit at all in the API.  And it is creating problems, as we can
see in this thread and people have to spend time to support this crude
hack, which doesn't add any functionality by itself, and fix problems
related to it.  NetBSD aims to be consistent and clean, how does
something like vfork fit in?

At the very least it should be marked as deprecated, and it certainly
should not be used for new applications (it's unportable anyways).

-- 
  Matthias Buelow;  mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}