Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!jsq
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-ID: <16369@cs.utexas.edu>
Date: 30 Dec 90 03:11:23 GMT
References: <16066@cs.utexas.edu> <16271@cs.utexas.edu> <16307@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 27
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ficc.ferranti.com (Peter da Silva)

In article <16307@cs.utexas.edu> jfh@rpp386.cactus.org (John F Haugh II) writes:
> what is probably needed is a "spawn()" function (god, i never thought i'd
> advocate such a critter) which can be responsible for understanding the
> legalese.

Wow, this is the same man who ever so politely flamed me for daring to make
such a suggestion. fork can be implemented on a large number of O/Ses, but
it's rather expensive. If the POSIX standard includes something like a
spawn(), that'll sure increase the efficiency of a lot of POSIX software on
systems that have been shoehorned into the model.

Yes, fork() is a cleaner method of creating new processes. Yes, it takes
a fairly complex calling sequence to get spawn() to have anything like
the functionality of fork()...exec(). But I think it'd be worthwhile to
let a little heresy in in exchange for making POSIX more palatable to
folks in poorer environments.

The few cases where spawn() won't fit would usually be better addressed by
something like threads anyway...
-- 
Peter da Silva.   `-_-'    "Eat hot digital death, mainframe scum!"
+1 713 274 5180.   'U`          -- Attack of the Killer Micros.
peter@ferranti.com

Volume-Number: Volume 22, Number 48