🚀 go-pugleaf

Submitted-by: mason@tmsoft.uucp (Dave Mason)

In article <16307@cs.utexas.edu> jfh@rpp386.cactus.org (John F Haugh II) writes:
>Submitted-by: jfh@rpp386.cactus.org (John F Haugh II)
>In article <16271@cs.utexas.edu> peter@ficc.ferranti.com (Peter da Silva) writes:
>>How about "executes any code that changes the state of the program". So,
>>for example:
>executing =any= code changes the state of the program.  that's the whole
>problem with this restriction - how much code is too much.

The real requirement is presumably: ``Must not execute any code that
changes MEMORY.'' As both the parent and child have their own register
sets.  Now, expressing that in a high-level way that is portable may
be quite a trick.  (Think of SPARC vs. 386 vs. HP/3000!)

>>At this point, unless I'm confused about legal interpretations of "qfork()",
>>the value of "child" is indeterminate.

Not if it's a register variable.

>what is probably needed is a "spawn()" function (god, i never thought i'd
>advocate such a critter) which can be responsible for understanding the
>legalese.  if the only thing you can do after "qfork()" is "exec()", why
>not merge the two steps into a single function?  sounds like the only way
>to get it right anyhow.

Not really.  Assuming qfork in the parent can make sure there is
nothing on its stack (that it needs to retrieve later) before it
executes the system call instruction, and the child doesn't do
anything except:
  a) make system calls that change its KERNEL state (open files, UID, etc.)
  b) change register variables
qfork can do everything useful that vfork can. (And because there's no
memory being changed by the child that can be inspected by the parent, a
fork implementation of qfork is still legal.)

(Personally I think the whole vfork/qfork/spawn thing is a horrible hack,
but if we're going to be stuck with it, lets at least do it right!)

-- 
"Don't break it if you can't fix it."                             ../Dave Mason
                                                  <mason%tmsoft@cs.toronto.edu>

Volume-Number: Volume 22, Number 49