Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cyb-eng.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!cyb-eng!howard
From: howard@cyb-eng.UUCP (Howard Johnson)
Newsgroups: net.unix-wizards
Subject: Re: fork timing hole? (yes)
Message-ID: <680@cyb-eng.UUCP>
Date: Wed, 21-Aug-85 17:25:26 EDT
Article-I.D.: cyb-eng.680
Posted: Wed Aug 21 17:25:26 1985
Date-Received: Sat, 24-Aug-85 17:51:18 EDT
References: <541@unisoft.UUCP> <671@cyb-eng.UUCP> <546@unisoft.UUCP>
Distribution: net
Organization: Cyb Systems, Austin, TX
Lines: 27

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