qfork() (again)
michael gersten
michael at CS.UCLA.EDU
Fri Jan 25 14:25:13 AEST 1991
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
More information about the Comp.std.unix
mailing list