qfork() (again)

[Dominic Dunlop]

Submitted-by: domo at tsa.co.uk (Dominic Dunlop)

In article <17402 at cs.utexas.edu> michael at CS.UCLA.EDU (michael gersten) writes:
> May I humbly ask what was wrong with vfork?

Yup.  I'll humbly try to answer.
> 
> As I understand it, vfork's semantics was a virtual fork--
> conceptually two execution threads would return from the call,
> and they may or may not be sharing data space--any program
> that relied on one or the other was by definition broken.

The problem -- one problem -- is in coming up with a ``portable''
definition of ``data space''.  On what we currently assume to be
``vanilla flavour'' architectures such as that of the 68000 which you
cite, it's fairly obvious.  But on others, it's not.  What about
registers?  Are they data space?  No?  Even on architectures with
register windows which may or may not map onto main memory addresses?
Bear in mind that such exotica are not so exotic any more: RISCs use
them widely.

It seems that any definition which is safe on all architectures is
liable to constrain what one may do between [qv]fork() and exec() so
greatly that it turns out to be better to define a combined spwan()
function.  This would make it less likely that the POSIX standards would
contain explicit or implicit assumptions about the architecture of the
hardware on which a conforming implementation runs.  While this might be
nice for aging architectures such as that of (say) the Unisys 1100
series, more importantly, it would not constrain architectural
advances of the future needlessly to conform to the nineteen
seventies' ideas of what was a ``clean machine'' in order to be able
efficiently to implement POSIX interfaces.

> Now, why was it removed? What is wrong with it?

-- see also comp.std.unix Volume 22, Number 69.
-- 
Dominic Dunlop

Volume-Number: Volume 22, Number 93