> To: leo@ahwau.ahold.nl (Leo Weppelman)
> Subject: Re: Hanging more(1) 
> Date: Thu, 27 Jul 1995 13:54:04 +0200
> From: Stefan Grefen <grefen@convex.com>
> 
> ...
> My guess is you're using (pd)ksh. (maybe every shell with comandline editing
> has the feature)
> There is a race condition setting up the terminal state (with ttioctl) in a 
> childprocess and setting the process group of the terminal from another child. 
> 
> One child gets a SIGTSTOP if tries to do the SETAW when the terminal doesn't
> belong to it's processgroup. (and sometimes the 2'nd child is faster and you see
> the hang. BTW. a SIGCONT should help here).
> 
> Best known fix, synchronise the parent shell with it child(s) through pipes
> or socketpairs.
> E.g. Wait for a child to gets it's termnial setting done before forking
> another one or, block the 2'nd child until it can savely change tty onwership.
> 
> ...
> 
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" ;-) ]