On Tue, 14 Apr 1998 15:10:00 +0930 
 Ian Dall <Ian.Dall@dsto.defence.gov.au> wrote:

 >   > 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.

vfork() can NOT be implemented as:

pid_t
vfork()
{

	return (fork());
}

...because vfork() has always been defined to block the parent until
the child either (a) exits, or (b) execs.

If you change that, you're looking at breaking a good number of applications.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939