home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0048.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.3 KB  |  30 lines
  1. Submitted-by: jason@cnd.hp.com (Jason Zions)
  2.  
  3. >Also, it should be remembered that unix systems don't execute C - they
  4. >execute machine instructions generated by the C compiler.  So it is
  5. >necessary to specify the behavior in machine terms if the compiler
  6. >writers are going to comply.  In particular, there is nothing to
  7. >prevent the compiler from moving certain computations to the space
  8. >between the qfork and the exec!  Does a compiler need to recognize
  9. >qfork and exec as special?
  10.  
  11. That's specious. Of *course* the compiler needs to recognize system calls as
  12. sync points. It wouldn't do for the compiler to migrate the instructions
  13. which initialize a write() buffer to after the write() call, would it?
  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. Um, how about "existing practice"? More than that, there's a whole raft of
  23. common extensions revolving around various forms of qfork() that many would
  24. like to see remain as possible extensions.
  25.  
  26. Jazz
  27.  
  28. Volume-Number: Volume 22, Number 50
  29.  
  30.