> vfork() problems only appear to have resurfaced wrt threading of
> late.  It doesn't add any functionality, per se,

But it did.  vfork() differed from fork() in two very important ways,
each of which could be useful: (1) the parent was automatically blocked
until the child execed or exited, and (2) memory writes done by the
child appeared in the parent.

The latter has, as far as I can tell, always been documented as a
"don't depend on this" property, but (as anyone with experience can
tell you would have happened) code was nevertheless written that
depended on it.

And with reason; it is awkward and rather ugly to set up _another_ pipe
between parent and child just to pass information back, with all the
failure modes that brings (most of which are can't-happens, but even if
you ignore them entirely, the code is significantly more complicated -
I know this because I've coded each way.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B