[ On Fri, April 10, 1998 at 10:18:05 (PDT), David Seifert wrote: ]
> Subject: forkexec(2)
>
> As you might imagine, people have considered a combined forkexec(2)
> before.  Many years ago someone looked through the source code and
> in most cases the program dinked around with file descriptors and
> such before doing the exec, thus a combined forkexec was deemed
> not worth bothering with.

I think many of those cases can be handled with a carefully designed
interface, and in some of the remaining cases the parent can contrive
the proper environment for the child and then undo it afterwards.

Doing things this way though would probably be more costly than simply
paying the price of a separate fork() + exec() [with COW, that is].

> Still, it seems like there could be cases where it would be a win.

I think it would obviously be a win everywhere that vfork() can be used
for the purpose it was originally intended, which is what we're really
talking about here anyway!  ;-)

I think the mistake previous attempts made was to look at the general
case of fork(), and not the specific case of vfork().

In any case we're talking about *adding* a forkexex() or spawn(), not
replacing fork()+exec() [which is what several non-unix-like operating
systems have attempted to do] and only eventually eliminating vfork()
through use of this new combined call.  And for those who do want the
memory sharing and/or blocking semantics there's also the option of
implementing a Plan-9-like rfork().  Best performance, best flexibility,
least danger due to inappropriate use.

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