home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v22 / 049 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  2.0 KB  |  46 lines
  1. Submitted-by: mason@tmsoft.uucp (Dave Mason)
  2.  
  3. In article <16307@cs.utexas.edu> jfh@rpp386.cactus.org (John F Haugh II) writes:
  4. >Submitted-by: jfh@rpp386.cactus.org (John F Haugh II)
  5. >In article <16271@cs.utexas.edu> peter@ficc.ferranti.com (Peter da Silva) writes:
  6. >>How about "executes any code that changes the state of the program". So,
  7. >>for example:
  8. >executing =any= code changes the state of the program.  that's the whole
  9. >problem with this restriction - how much code is too much.
  10.  
  11. The real requirement is presumably: ``Must not execute any code that
  12. changes MEMORY.'' As both the parent and child have their own register
  13. sets.  Now, expressing that in a high-level way that is portable may
  14. be quite a trick.  (Think of SPARC vs. 386 vs. HP/3000!)
  15.  
  16. >>At this point, unless I'm confused about legal interpretations of "qfork()",
  17. >>the value of "child" is indeterminate.
  18.  
  19. Not if it's a register variable.
  20.  
  21. >what is probably needed is a "spawn()" function (god, i never thought i'd
  22. >advocate such a critter) which can be responsible for understanding the
  23. >legalese.  if the only thing you can do after "qfork()" is "exec()", why
  24. >not merge the two steps into a single function?  sounds like the only way
  25. >to get it right anyhow.
  26.  
  27. Not really.  Assuming qfork in the parent can make sure there is
  28. nothing on its stack (that it needs to retrieve later) before it
  29. executes the system call instruction, and the child doesn't do
  30. anything except:
  31.   a) make system calls that change its KERNEL state (open files, UID, etc.)
  32.   b) change register variables
  33. qfork can do everything useful that vfork can. (And because there's no
  34. memory being changed by the child that can be inspected by the parent, a
  35. fork implementation of qfork is still legal.)
  36.  
  37. (Personally I think the whole vfork/qfork/spawn thing is a horrible hack,
  38. but if we're going to be stuck with it, lets at least do it right!)
  39.  
  40. -- 
  41. "Don't break it if you can't fix it."                             ../Dave Mason
  42.                                                   <mason%tmsoft@cs.toronto.edu>
  43.  
  44. Volume-Number: Volume 22, Number 49
  45.  
  46.