> Is the new vfork() really the right answer to the problem, i.e.
> would we be better off finding the reasons why the VM/fork() is
> so damn slow and fixing that rather than just rehashing vfork()?

Speeding up VM is always a good idea, but there are also some limits
to how much of a speedup it's possible to get while maintaining a
clean interface.

> vfork() has always struck me as having way too many "gotcha's" to
> remember, getting VM/fork() speeded up in general would seem a
> better long term solution.

Vfork is a speed hack.  It's warty.  It runs a little closer to the
hot metal than is comfortable.  If you don't like that, you're not
required to use it!  Fork() will work just fine - it's just slower.
If you're not writing something that forks a lot, that's perfectly
okay.  But there are definitely cases where speed hacks can be a big
win - places where a lot of forks happen.  In an ideal world, the
speed hack would be transparent, but this isn't an ideal world.
Besides, wouldn't the world be an unpleasant place if there were no
black magic anywhere to puzzle and delight young computer nerds?

			       _MelloN_