Subject: Re: Real vfork() (was: third results)
To: None <tech-kern@NetBSD.ORG>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
List: tech-kern
Date: 04/14/1998 15:10:00
woods@most.weird.com (Greg A. Woods) writes:

  >      The vfork() function has the same effect as fork(), except that the
  >      behaviour is undefined if the process created by vfork() either  
  >      modifies any data other than a variable of type pid_t used to store
  >      the return value from vfork(), or returns from the function in
  >      which vfork() was called, or calls any other function before 
  >      successfully calling _exit() or one of the exec family of
  >      functions.

  > Under the "APPLICATION USAGE" it says that on some systems vfork() is
  > the same as fork(), or on others that the child it creates "*can* share
  > code and data with the calling process" (emphasis added).

Yes, my view is that vfork should be defined so that an implimentation
can always impliment vfork as  "pid_t vfork(void){return fork();}" but can
optionally impliment it with shared memory semantics as a performance
enhancement. This allows maximum portability.

Ian