Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!swrinde!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: <16992@cs.utexas.edu>
Date: 14 Jan 91 14:19:09 GMT
References: <16066@cs.utexas.edu> <16213@cs.utexas.edu> <16875@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 51
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 <16875@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
> because it was not necessary, given a decent implementation of fork().

POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
environments a "decent implementation of fork" is quite difficult and
may even be impossible. A poor implementation of fork() is likely to
clobber performance, given how common it is in UNIX code.

I suspect that in practice most implementations will use an efficient
call in the internals of system() and similar library routines. Either
direct spawns or an implementatio of qfork that looks something like:

	qfork()
	{
		Save stack context.
		Vector open(), exit(), etc to pseudo routines that
			save flags (either adjust jump table or set
			a flag that tells open we're "in a qchild".
		Return 0;
	}

	qopen() /* new version of open */
	{
		open file, save descriptor
	}
	...

	qexec() /* new version of exec */
	{
		call spawn, passing it the info for the new execution
			environment (juggling fds, signals, etc).
		Return execution environment to the one set up back
			at the qfork (juggle fds, etc)
		longjump back to saved stack context, returning child pid.
	}

This gets around the cost of creating a new execution context that will
simply be juggled briefly and discarded.

Something like this will be needed to get decent performance out of systems
like VMS where creating a new process is quite expensive. Why not standardise
this so portable programs can take advantage of it?
-- 
Peter da Silva.   `-_-'   "Have you hugged your wolf today?"
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 22, Number 68