Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: The trouble with fork() (Re: IBM PC prehistory)
Message-ID: <11969@smoke.BRL.MIL>
Date: 17 Jan 90 14:31:07 GMT
References: <7413@drilex.UUCP> <380@bambam.UUCP> <44106@wlbr.IMSD.CONTEL.COM> <610@ssp11.idca.tds.philips.nl> <DW31DR7xds13@ficc.uu.net>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 14

In article <DW31DR7xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>Wouldn't it be nice if there was a sanctioned P1003 subset that replaced
>fork() with a combined fork()/exec() call (spawn?). Or just an addition
>of spawn to the standard as an alternative process creation mechanism:
>This would radically improve the performance of non-UNIX POSIX systems,
>without compromising the capability of the standard...

Wrong; fork() is more flexible than spawn(), and this is thoroughly
exploited by UNIX applications.  For example, a job control shell
has many things to do between the fork() and the exec() in the child
branch.

IEEE P1003 decided early on not to compromise UNIX semantics merely
to allow POSIX to be more readily implemented on non-UNIX platforms.