[ On Thu, April 9, 1998 at 16:24:46 (-0700), Jason Thorpe wrote: ]
> Subject: Re: Real vfork() (was: third results) 
>
> I don't think so, no... for a few reasons:
> 
> 	(1) No other UNIX-like system has that.

When has that ever been an excuse?  ;-)

But, I don't think that's even true, esp. if you use the old-fashioned
definition of "UNIX-like" where adherance to modern standards is *not* a
consideration.  Doesn't QNX have spawn(), and it certainly claims itself
to be UNIX-like, at least if they're trying to sell it to a UNIX user.

> 	(2) vfork(2) is actually documented in a standard now.

Or, for that matter, this?  That's like documenting a bug and then
saying that you have to preserve the bug because you made the mistake of
telling people about it -- i.e. you promote a bug to a feature and it
pokes you in the ribs forever more.

> 	(3) vfork(2) is an "expected" interface for this sort of thing.

Only in the BSD world, though I admit the rest of the world has
drastically shrunk since BSD, and esp. Linux, became freely available,
and indeed since SysVr4 tried to bridge the gaps.  Some all-too-common
commercial platforms still don't have vfork() though [eg. IRIX-5.3].
Indeed it seems vfork() is doomed to oblivion in SunOS-5 too, at least
according to the 5.4 manual page (they've got light-weight processes to
take its place anyway).

> 	(4) It makes decoding the error in the parent slightly more
> 	    difficult.

Hmmm.....  Really?  How?  The only current "collision" of errno values I
see between fork() and execve() seems to be ENOMEM, and I don't think it
really matters which part of the operation has failed when that one
comes back.  There's already a great deal of overloading of errno values
in those individual systems calls, and esp. for execve() enough to make
decoding the true cause of an error quite difficult in any case.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>