In article <199507272109.PAA13394@venus.cs.utah.edu> mike@cs.utah.edu (Mike Hibler) writes:
>Following is a historical tidbit, it won't help solve your problem :-)
>
>Wow, this brings back memories!  When I first put the Mach VM into BSD
>I initially did the obvious thing and implemented vfork() as fork().  I
>knew that the odd semantic feature where parent and child share memory
>might cause a problem but in practice I didn't think it would.  I was right,
>but there is another feature of vfork which, when missing, causes exactly
>the problem you describe.  In vfork you are guarenteed that the parent will
>not return from the vfork call until after the child execs or exits.
>Hence there is an implied synchronization that doesn't exist in fork.
>
>I had to add back this syncronization in the 4.4 vfork emulation.
>This is why the PPWAIT process flag still exists in 4.4.
>
>[ Note, I only said it would be "historical" not "interesting" ;-) ]
>

Some more interesting trivia about this:

/bin/csh is the only program I know of that uses both features of vfork():

1. The guarantee that the parent will be suspended until the child execs
   or exits to fork pipelines in the correct order.
2. The ability of the child to write to the parent's address space to
   record statistics about finding executables in the path [hashstat]

christos