> : Hmm, I know it's probably only me, but IMHO vfork _is_ a bug.
> 
> I know you're not the only one that feels that way, but I believe it isn't
> for the following reasons:
> 
> - Not all machines are truthfully fast enough to make copying a bunch of
>   copy-on-write pmap pages efficient.  Much less an entire process space
>   like very old fork()s did.

Since you don't copy pages, this shouldn't be the problem.

> - With vfork(), the page maps are created only once, as opposed to twice
>   with fork().  (Once at fork time, once at exec time.)

This isn't the problem either.  The page maps aren't created twice.  The
fork creates a new pmap, but the exec only clears it.  The copying of the
vmspace on the fork is probably the problem (in addition to the added write
faults in the parent due to cow).  Probably some instrumentation is needed
here.

> - We don't have something more efficient like a function that forks and
>   execs simultaneously.
> - fork() is a sensationally old hack in itself.  So don't rag on vfork().
>   <g>

Bogus.  The separation of fork and exec was a deliberate design decision with
U*X.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800