Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: donn@hpfcdc.fc.hp.com (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16479@cs.utexas.edu>
Date: 3 Jan 91 15:59:27 GMT
References: <16307@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Lines: 24
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: donn@hpfcdc.fc.hp.com (Donn Terry)

To add to the qfork discussion:

1) The purpose of qfork() is similar to that of vfork(), but detailed 
   discussions end up showing that there really is nothing that is safe
   to do between the qfork() and the exec() that will not cause problems
   on some architecture or other.  That's the reason for the name change
   from vfork().

2) 1003.5 (Ada) has a entry point "start_process[_search]" which are
   a spawn()-like animal that takes a data structure to tell it what to
   do with file descriptors, user ID's and the like between the fork()
   and exec() that underly it.  (In Ada, fork() + exec() is "unsafe";
   "unsafe" is a dirty word in the Ada community.)

   This might be (observation of fact, not an opinion) a place to start
   for something that does serve the fork(), do a few safe things, exec()
   sequence.

Donn Terry
Speaking only for myself.

Volume-Number: Volume 22, Number 56