home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0056.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.2 KB  |  48 lines
  1. Submitted-by: lewine@cheshirecat.rtp.dg.com (Donald Lewine)
  2.  
  3. In article <16213@cs.utexas.edu>, jason@cnd.hp.com (Jason Zions) writes:
  4. |> 
  5. |> I think that loosens the restriction too much.  The intent of the text, I
  6. |> believe, is that *doing* anything between qfork() and exec*() results in
  7. |> undefined behavior. Checking a variable doesn't *do* anything in this sense.
  8. |> The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
  9. |> share-memory pseudo-fork or is it a real fork or what?" An application which
  10. |> takes an action after qfork() and before exec*() that depends upon the
  11. |> implementation of qfork() being any one of those things is inherently
  12. |> unportable.
  13. |> 
  14. |> Instead of replacing "executes any code", I think you could just add the
  15. |> phrase "which modifies memory or calls any function" and maintain the
  16. |> intent. Examining variables doesn't depend upon the virtual memory
  17. |> relationship between child and parent, but munging a stack for a function
  18. |> call might behave differently and hence must be rendered undefined.
  19. |> 
  20.  
  21.     I think I would vote "NO" on qfork().  I think that there are 
  22.     two better solutions:
  23.     (1) Just use fork() and require the implementation to do it
  24.         in an efficient manner.
  25.     (2) Add some new functions (fexec() ?) which do the fork() and
  26.         exec() in one call.  I know that this is not existing practice
  27.         but neither was sigemptyset() or tcgetispeed().  This may be
  28.         another case where it is better to define a new interface than
  29.         to try to describe the existing practice.  [[Also, qfork() is
  30.         not quite vfork() so it can be shot down on the same basis.]]
  31.  
  32.     As I think about it, (2) is a much nicer solution to the problem
  33.     than qfork().  The library can then implement fexecl() as a vfork()
  34.     followed by an execl() or a fork() followed by an execl().  The 
  35.     error handling is clean and the semantics are obvious.
  36.  
  37.  
  38. --------------------------------------------------------------------
  39. Donald A. Lewine                (508) 870-9008 Voice
  40. Data General Corporation        (508) 366-0750 FAX
  41. 4400 Computer Drive. MS D112A
  42. Westboro, MA 01580  U.S.A.
  43.  
  44. uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com
  45.  
  46. Volume-Number: Volume 22, Number 58
  47.  
  48.