home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0042.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.0 KB  |  28 lines
  1. Submitted-by: marc@arnor.uucp
  2.  
  3. It would be useful to know why the function is being proposed.  One
  4. assumes an efficiency improvement, which implies that the specifiers
  5. have an implementation in mind.
  6.  
  7. Also, it should be remembered that unix systems don't execute C - they
  8. execute machine instructions generated by the C compiler.  So it is
  9. necessary to specify the behavior in machine terms if the compiler
  10. writers are going to comply.  In particular, there is nothing to
  11. prevent the compiler from moving certain computations to the space
  12. between the qfork and the exec!  Does a compiler need to recognize
  13. qfork and exec as special?
  14.  
  15. Finally - if the intent is to "bundle" fork and exec together,
  16. assuming only that the fork succeeds, would it not be better to
  17. propose fexec* - a set of exec calls which fork first?  Of course,
  18. this makes it absolutely clear that nothing can happen between fork
  19. and exec.  If the combined function is then deemed useless, how can
  20. the qfork/exec idiom be better?
  21. --
  22.  
  23. Marc Auslander       <marc@ibm.com>
  24.  
  25.  
  26. Volume-Number: Volume 22, Number 44
  27.  
  28.