home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0038.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.5 KB  |  36 lines
  1. Submitted-by: jason@cnd.hp.com (Jason Zions)
  2.  
  3. >"The qfork() function shall be identical to the fork() function with
  4. > the following exception: behavior is undefined if the child process
  5. > executes any code between the return from qfork() and the succeeding
  6. > call to one of the exec functions or _exit()."
  7. >
  8. >This seems to be a very harsh restriction.  The following code seems
  9. >like it would be undefined:
  10. >    status = qfork();
  11. >    if (status == 0) execve(...);
  12. >
  13. >I would propose replacing the phrase: "executes any code" with "calls
  14. >any function defined in this standard or the C standard {8}"  I think
  15. >that does what you mean.
  16.  
  17. I think that loosens the restriction too much.  The intent of the text, I
  18. believe, is that *doing* anything between qfork() and exec*() results in
  19. undefined behavior. Checking a variable doesn't *do* anything in this sense.
  20. The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
  21. share-memory pseudo-fork or is it a real fork or what?" An application which
  22. takes an action after qfork() and before exec*() that depends upon the
  23. implementation of qfork() being any one of those things is inherently
  24. unportable.
  25.  
  26. Instead of replacing "executes any code", I think you could just add the
  27. phrase "which modifies memory or calls any function" and maintain the
  28. intent. Examining variables doesn't depend upon the virtual memory
  29. relationship between child and parent, but munging a stack for a function
  30. call might behave differently and hence must be rendered undefined.
  31.  
  32. Jason Zions
  33.  
  34. Volume-Number: Volume 22, Number 39
  35.  
  36.