Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!sdd.hp.com!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!jsq
From: domo@tsa.co.uk (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-ID: <16993@cs.utexas.edu>
Date: 14 Jan 91 18:21:56 GMT
References: <16369@cs.utexas.edu> <16478@cs.utexas.edu> <16871@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: domo@tsa.co.uk
Organization: The Standard Answer Ltd.
Lines: 19
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: domo@tsa.co.uk (Dominic Dunlop)

For those who have been following this issue, last week's meeting of
1003.1 decided that [qv]fork() would be dropped from the next draft of
1003.1a, the extensions to POSIX.1.  It will be replaced in the next
or a subsequent draft with a proposal for a spawn() family, analogous to
the exec() family.  Work already done by 1003.5 (Ada bindings) on an
interface of this type will be taken into account, and the opportunity
will be taken to address some very knotty problems which arise when one
thread out of many in a single process decides to replace the whole
process image.  Threads are strictly a 1003.4 (realtime) issue, but it
makes sense for any new interface proposed by 1003.1 in this area 
make life easier for 1003.4, rather than more difficult.  (Cue 1003.4
folks, to tell us all what a pig fork-exec is in a multi-threaded
process.)
-- 
Dominic Dunlop

Volume-Number: Volume 22, Number 69