home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v22 / 093 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  1.8 KB  |  42 lines
  1. Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  2.  
  3. In article <17402@cs.utexas.edu> michael@CS.UCLA.EDU (michael gersten) writes:
  4. > May I humbly ask what was wrong with vfork?
  5.  
  6. Yup.  I'll humbly try to answer.
  7. > 
  8. > As I understand it, vfork's semantics was a virtual fork--
  9. > conceptually two execution threads would return from the call,
  10. > and they may or may not be sharing data space--any program
  11. > that relied on one or the other was by definition broken.
  12.  
  13. The problem -- one problem -- is in coming up with a ``portable''
  14. definition of ``data space''.  On what we currently assume to be
  15. ``vanilla flavour'' architectures such as that of the 68000 which you
  16. cite, it's fairly obvious.  But on others, it's not.  What about
  17. registers?  Are they data space?  No?  Even on architectures with
  18. register windows which may or may not map onto main memory addresses?
  19. Bear in mind that such exotica are not so exotic any more: RISCs use
  20. them widely.
  21.  
  22. It seems that any definition which is safe on all architectures is
  23. liable to constrain what one may do between [qv]fork() and exec() so
  24. greatly that it turns out to be better to define a combined spwan()
  25. function.  This would make it less likely that the POSIX standards would
  26. contain explicit or implicit assumptions about the architecture of the
  27. hardware on which a conforming implementation runs.  While this might be
  28. nice for aging architectures such as that of (say) the Unisys 1100
  29. series, more importantly, it would not constrain architectural
  30. advances of the future needlessly to conform to the nineteen
  31. seventies' ideas of what was a ``clean machine'' in order to be able
  32. efficiently to implement POSIX interfaces.
  33.  
  34. > Now, why was it removed? What is wrong with it?
  35.  
  36. -- see also comp.std.unix Volume 22, Number 69.
  37. -- 
  38. Dominic Dunlop
  39.  
  40. Volume-Number: Volume 22, Number 93
  41.  
  42.