Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!jsq
From: rml@hpfcdc.fc.hp.com (Bob Lenk)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-ID: <16996@cs.utexas.edu>
Date: 15 Jan 91 21:24:11 GMT
References: <16895@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Lines: 33
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk)

In article <16895@cs.utexas.edu> jfh@rpp386.cactus.org (John F Haugh II) writes:

> Again, the problem you are alluding to results from the choice of early
> or late allocation of paging space.  If you choose early allocation, you
> are correct - you can't fork() a 30MB process with only 20MB remaining.
> And yes, if you choose late allocation it is possible to deadlock, but
> only in the cases where you are doing more than you are with vfork().

This sounds like a good argument for two mechanisms, one with early
allocation and the other with late (or perhaps no) allocation.  If the
OS chooses blindly from a single interface (fork) it will sometimes
choose "wrong" according to the needs of the application.  There could
be an interface to select the behavior of fork() rather than two
separate calls; there are some advantages to each approach.

In what I've read in this discussion about qfork(), I'm nervous about
the spec that *nothing* is permitted between it and exec.  If nothing is
permitted portably, then a single spawn call should be defined.  The
whole advantage of separate calls is that things *can* be done in
between.  People will take advantage of this even if the standard calls
the behavior implementation-defined, unspecified, or undefined, and the
result is that people will write less-than-portable code.  If the
standard defines qfork(), I think it should define a useful set of
operations permitted with well-defined results in the child prior to
exec.

		Bob Lenk
		rml@fc.hp.com
		{uunet,hplabs}!fc.hp.com!rml

Volume-Number: Volume 22, Number 72