home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0062.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.2 KB  |  34 lines
  1. Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  2.  
  3. >By now we
  4. >know that in a ``from to ground up'' virtual memory implementation of
  5. >UNI*X with a half-way useful memory management hardware copy on write and
  6. >similar finessing can make the general-case fork() call as efficient as
  7. >any special-case variant, and, unlike the variants, is free from any
  8. >threat that sixteen ton weights will be dropped on any programmer who
  9. >steps out of line.
  10.  
  11. You should also know that copy-on-write fork(), unlike vfork(), is inherently
  12. buggy and can not be a general-purpose useful memory management mechanism.
  13.  
  14. If you have 50MB swap space and want to fork() 30MB process to exec less
  15. than 1MB shell, you can't. With COW fork(), there is workaround. But the
  16. workaround is so incomplete that the system sometimes deadlocks.
  17.  
  18. Thus, fork(), even COW fork(), is not a proper mechanism to fork-exec
  19. other processes.
  20.  
  21. If you insist on using fork(), someday, thirtytwo ton weights will drop on
  22. your head.
  23.  
  24.                         Masataka Ohta
  25.  
  26. PS
  27.  
  28. I can't understand why the name vfork() is changed to qfork(). On crippled
  29. systems which can not support true vfork(), the implementors can make vfork()
  30. just fork(). It is actually done on NeXT. What's wrong with that?
  31.  
  32. Volume-Number: Volume 22, Number 64
  33.  
  34.