qfork() (again)

[michael gersten]

Submitted-by: michael at CS.UCLA.EDU (michael gersten)

In article <17010 at cs.utexas.edu> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>Submitted-by: gwyn at smoke.brl.mil (Doug Gwyn)
>
>In article <16992 at cs.utexas.edu> peter at ficc.ferranti.com (Peter da Silva) writes:
>>In article <16875 at cs.utexas.edu> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>>> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
>>> because it was not necessary, given a decent implementation of fork().
>>POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
>>environments a "decent implementation of fork" is quite difficult ...
>
>Excuse me, but you're quite wrong.  P1003 decided deliberately that we
>(I was there) would not compromise the (1003.1) interface in order to
>accommodate "layered" implementations, for example on non-UNIX based
>operating system kernels.


May I humbly ask what was wrong with vfork?

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.

Now, with that definition, vfork() is pretty trivial to implement,
even on a naked 68000 with no mmu. And on better, more complete
systems, it can be identical to fork.

So its a call that is at least, if not more, efficient on a larger
variety of hardware platforms.

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

Volume-Number: Volume 22, Number 82