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