Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: eggert@twinsun.uucp (Paul Eggert)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-ID: <17572@cs.utexas.edu>
Date: 1 Feb 91 02:18:25 GMT
References: <16992@cs.utexas.edu> <17010@cs.utexas.edu> <17402@cs.utexas.edu> <17527@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Twin Sun, Inc
Lines: 34
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: eggert@twinsun.uucp (Paul Eggert)

	... any definition which is safe on all architectures is liable to
	constrain what one may do between [qv]fork() and exec() so greatly
	that it turns out to be better to define a combined spawn() function.

What's wrong with the following definition, which permits the usual actions
between fork() and exec()?  Isn't this definition easy to explain and support?

	vfork() acts like fork(), except:

	1.  Any variables that are common to both parent and child, and are
	changed by the child before it exits or execs, have undefined values in
	the parent when its vfork() returns.

	2.  The child may not call unsafe standard functions (these are
	nonreentrant; see Posix 1003.1-1988 section 3.3.1.3(3)(f)).

	3.  The child may not return from the function that called vfork(),
	either explicitly or via longjmp().

	4.  The program must #include <vfork.h>.

(2) follows from (1).  (4) is common practice, and gets around the exotic
architecture problem.  (2)'s phrase ``common to both parent and child'' lets
the child call reentrant functions, because their automatic variables do not
exist in the parent.

I don't much like vfork(), but it's common practice, it is much faster on many
hosts, and many widely distributed Unix programs use it.  By all means, let's
invent other primitives if they're needed, but why not first standardize the
primitives we already have?

Volume-Number: Volume 22, Number 96