Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!texbell!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.questions Subject: Re: The trouble with fork() (Re: IBM PC prehistory) Message-ID: Date: 18 Jan 90 02:47:27 GMT References: <7413@drilex.UUCP> <380@bambam.UUCP> <44106@wlbr.IMSD.CONTEL.COM> <610@ssp11.idca.tds.philips.nl> <11969@smoke.BRL.MIL> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 22 In article <11969@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article 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. Read my lips: no new taxes. Oops. Wrong program. Anyway, look at the second sentence above. Most cases of fork/exec could be replaced by a simple spawn call, making the majority of programs that didn't need fork/exec more efficient. How do you feel about adding coroutines to C? -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'