home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v22 / 096 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  1.4 KB  |  36 lines
  1. Submitted-by: eggert@twinsun.uucp (Paul Eggert)
  2.  
  3.     ... any definition which is safe on all architectures is liable to
  4.     constrain what one may do between [qv]fork() and exec() so greatly
  5.     that it turns out to be better to define a combined spawn() function.
  6.  
  7. What's wrong with the following definition, which permits the usual actions
  8. between fork() and exec()?  Isn't this definition easy to explain and support?
  9.  
  10.     vfork() acts like fork(), except:
  11.  
  12.     1.  Any variables that are common to both parent and child, and are
  13.     changed by the child before it exits or execs, have undefined values in
  14.     the parent when its vfork() returns.
  15.  
  16.     2.  The child may not call unsafe standard functions (these are
  17.     nonreentrant; see Posix 1003.1-1988 section 3.3.1.3(3)(f)).
  18.  
  19.     3.  The child may not return from the function that called vfork(),
  20.     either explicitly or via longjmp().
  21.  
  22.     4.  The program must #include <vfork.h>.
  23.  
  24. (2) follows from (1).  (4) is common practice, and gets around the exotic
  25. architecture problem.  (2)'s phrase ``common to both parent and child'' lets
  26. the child call reentrant functions, because their automatic variables do not
  27. exist in the parent.
  28.  
  29. I don't much like vfork(), but it's common practice, it is much faster on many
  30. hosts, and many widely distributed Unix programs use it.  By all means, let's
  31. invent other primitives if they're needed, but why not first standardize the
  32. primitives we already have?
  33.  
  34. Volume-Number: Volume 22, Number 96
  35.  
  36.