home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: michael@CS.UCLA.EDU (michael gersten)
-
- In article <17010@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
- >Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
- >
- >In article <16992@cs.utexas.edu> peter@ficc.ferranti.com (Peter da Silva) writes:
- >>In article <16875@cs.utexas.edu> gwyn@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
-
-