On Fri, Sep 12, 2003 at 12:09:20PM +0530, Kamal R Prasad wrote:
> 
> It came into being because memory was precious a few decades back and the 
> only way to provide concurrency was to fork()+exec() which would mean 
> copying a lot of pages unnecssarily [depending on how pro-active the VM 
> was]. vfork() is in a way unnecessary right now.

You need to stop drinking the kool-aid and actually do some measurements.
Doing copy-on-write and faulting in all of the child's new pages is 
*expensive*; in some cases, depending on the cost of a fault and the memory 
copy bandwidth of your system, maybe even more expensive than actually 
copying everything ala early Unix fork().  Despite the appealing nature of 
the claim that vfork() doesn't win, it is in fact still false -- vfork() is 
a *big* win in many cases, even if your system fork() does copy-on-write.
Even if you immediately exec() and have the obvious optimization, there is
a substantial cost just to creating the new address space for the child;
vfork() was put back into NetBSD for a reason: it wins.