home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v22 / 068 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  1.7 KB  |  53 lines
  1. Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
  2.  
  3. In article <16875@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
  4. > We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
  5. > because it was not necessary, given a decent implementation of fork().
  6.  
  7. POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
  8. environments a "decent implementation of fork" is quite difficult and
  9. may even be impossible. A poor implementation of fork() is likely to
  10. clobber performance, given how common it is in UNIX code.
  11.  
  12. I suspect that in practice most implementations will use an efficient
  13. call in the internals of system() and similar library routines. Either
  14. direct spawns or an implementatio of qfork that looks something like:
  15.  
  16.     qfork()
  17.     {
  18.         Save stack context.
  19.         Vector open(), exit(), etc to pseudo routines that
  20.             save flags (either adjust jump table or set
  21.             a flag that tells open we're "in a qchild".
  22.         Return 0;
  23.     }
  24.  
  25.     qopen() /* new version of open */
  26.     {
  27.         open file, save descriptor
  28.     }
  29.     ...
  30.  
  31.     qexec() /* new version of exec */
  32.     {
  33.         call spawn, passing it the info for the new execution
  34.             environment (juggling fds, signals, etc).
  35.         Return execution environment to the one set up back
  36.             at the qfork (juggle fds, etc)
  37.         longjump back to saved stack context, returning child pid.
  38.     }
  39.  
  40. This gets around the cost of creating a new execution context that will
  41. simply be juggled briefly and discarded.
  42.  
  43. Something like this will be needed to get decent performance out of systems
  44. like VMS where creating a new process is quite expensive. Why not standardise
  45. this so portable programs can take advantage of it?
  46. -- 
  47. Peter da Silva.   `-_-'   "Have you hugged your wolf today?"
  48. +1 713 274 5180.   'U`
  49. peter@ferranti.com
  50.  
  51. Volume-Number: Volume 22, Number 68
  52.  
  53.