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