Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!jsq
From: eggert@twinsun.uucp (Paul Eggert)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16245@cs.utexas.edu>
Date: 26 Dec 90 21:22:33 GMT
References: <16066@cs.utexas.edu> <16213@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Twin Sun, Inc
Lines: 19
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

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

jason@cnd.hp.com (Jason Zions) writes:

  The intent of the [Posix.1a draft 5] text, I believe, is that *doing* anything
  between qfork() and exec*() [or _exit()] results in undefined behavior.

I hope this is not the intent.  Current applications often do the following
actions between forking and execing in a child process:

	Redirect file descriptors using open(), close(), dup2().
	Call write() and _exit() if the exec*() fails.
	Change signal handling, uid/gid/pgid/session, working/root directory.
	Call user-defined functions that modify their local variables.

Both fork() and vfork() permit these actions.  Why should qfork() prohibit them?


Volume-Number: Volume 22, Number 42