home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0083.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.5 KB  |  37 lines

  1. Submitted-by: michael@CS.UCLA.EDU (michael gersten)
  2.  
  3. In article <17010@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
  4. >Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  5. >
  6. >In article <16992@cs.utexas.edu> peter@ficc.ferranti.com (Peter da Silva) writes:
  7. >>In article <16875@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
  8. >>> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
  9. >>> because it was not necessary, given a decent implementation of fork().
  10. >>POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
  11. >>environments a "decent implementation of fork" is quite difficult ...
  12. >
  13. >Excuse me, but you're quite wrong.  P1003 decided deliberately that we
  14. >(I was there) would not compromise the (1003.1) interface in order to
  15. >accommodate "layered" implementations, for example on non-UNIX based
  16. >operating system kernels.
  17.  
  18.  
  19. May I humbly ask what was wrong with vfork?
  20.  
  21. As I understand it, vfork's semantics was a virtual fork--
  22. conceptually two execution threads would return from the call,
  23. and they may or may not be sharing data space--any program
  24. that relied on one or the other was by definition broken.
  25.  
  26. Now, with that definition, vfork() is pretty trivial to implement,
  27. even on a naked 68000 with no mmu. And on better, more complete
  28. systems, it can be identical to fork.
  29.  
  30. So its a call that is at least, if not more, efficient on a larger
  31. variety of hardware platforms.
  32.  
  33. Now, why was it removed? What is wrong with it?
  34.  
  35. Volume-Number: Volume 22, Number 82
  36.  
  37.