fork timing hole? (yes)

[Howard Johnson]

> > >	... [wild speculation]
> 
> You miss my point, cases 1 and 2 I don't care about, but the third case ....
> where the parent gets the signal and the child continues without receiving
> the signal is the interesting one.

	Your original posting did not focus strongly enough on the desired
issue; I see now what you were trying to say.  After perusing source code
for psignal(), fork(), newproc(), etc. in the kernel, I believe that the
race condition exists.  I believe that signals should be inherited from
the parent process in newproc().  Thus,

	...
	rpp->p_sigign = rip->p_sigign;
+	rpp->p_sig = rip->p_sig;
	...

(in newproc()) should close up the race condition you described (if the
added statment is made uninterruptible) without ill effect.

	I still think that the behavior you described (ls <CR><DEL>)
could also be caused by the child process receiving the signal after
it has called exit()--provided that the "ls" wasn't run on some huge
directory such as /bin or /usr/src/cmd.
-- 
..!{seismo,topaz,mordor,harvard,gatech,nbires,ihnp4}!ut-sally!cyb-eng!howard
(ordered best to worst); also ..!{ut-ngp,shell}!cyb-eng!howard  +1 512 458 6609