[ On Wed, April 15, 1998 at 21:54:35 (-0700), Ted Lemon wrote: ]
> Subject: Re: Real vfork() (was: third results) 
>
> BTW - there are a lot of people participating in this
> particular waste of bandwidth.

That just goes to show you that *you* might think it's a waste of
bandwith, but others think it's an issue worth discussion -- i.e. they
have opinions or strong feelings on it one way or another.  ;-)

As for "getting somewhere" with this discussion, I might remind those
who aren't already painfully aware of it that this discussion has been
going on in spurts since long long ago.  I first came across it in about
1982, but I'm sure it had been debated even before that, perhaps all the
way back to Unix V5 or even before (did Multics start this debate, at
least within Bell Labs?).

If I ever get a spare moment, and a decent enough play environment, I do
intend to whip up a forkexec() or spawn() or similar in the kernel and
see just how many vfork()s I can eliminate with it, and what kind of
performance impact it may have.  However that's not likely to be "soon"
(I've no idea where it might fit into the priority list of all the other
projects I'd like to work on too), so don't let me discourage anyone
else from trying the same thing!  ;-) It's probably even worth a paper
for something like Usenix, etc.

As kre has reminded us "programs that don't work when compiled with
-Dvfork=fork are broken, pure and simple."  However finding this out is
sometimes difficult and painful.  If there's a better way to achieve the
same performance for this class of problem, but without the painfulness
of finding far too late that some programmer has misused your finely
tuned interface in such a way that his program won't run in other
environments, then I for one would like to explore it.  Clearly a better
interface is necessary and I think there are now enough existing
attempts to look at out there that devising a good one for unix may be
possible, if indeed it hasn't been done already.

-- 
							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>