Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: jason@cnd.hp.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16213@cs.utexas.edu>
Date: 24 Dec 90 16:57:44 GMT
References: <16066@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Hewlett Packard, Information Networks Group
Lines: 34
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jason@cnd.hp.com (Jason Zions)

>"The qfork() function shall be identical to the fork() function with
> the following exception: behavior is undefined if the child process
> executes any code between the return from qfork() and the succeeding
> call to one of the exec functions or _exit()."
>
>This seems to be a very harsh restriction.  The following code seems
>like it would be undefined:
>	status = qfork();
>	if (status == 0) execve(...);
>
>I would propose replacing the phrase: "executes any code" with "calls
>any function defined in this standard or the C standard {8}"  I think
>that does what you mean.

I think that loosens the restriction too much.  The intent of the text, I
believe, is that *doing* anything between qfork() and exec*() results in
undefined behavior. Checking a variable doesn't *do* anything in this sense.
The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
share-memory pseudo-fork or is it a real fork or what?" An application which
takes an action after qfork() and before exec*() that depends upon the
implementation of qfork() being any one of those things is inherently
unportable.

Instead of replacing "executes any code", I think you could just add the
phrase "which modifies memory or calls any function" and maintain the
intent. Examining variables doesn't depend upon the virtual memory
relationship between child and parent, but munging a stack for a function
call might behave differently and hence must be rendered undefined.

Jason Zions

Volume-Number: Volume 22, Number 39