qfork()

[Doug Gwyn]

Submitted-by: gwyn at smoke.brl.mil (Doug Gwyn)

In article <16213 at cs.utexas.edu> jason at cnd.hp.com (Jason Zions) writes:
>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?"

We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
because it was not necessary, given a decent implementation of fork().
Why is this notion being reintroduced (quite carelessly so far as I can
tell from the quotes so far) for 1003.1a?

Volume-Number: Volume 22, Number 66