Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rti-sel.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!mcnc!rti-sel!trt From: trt@rti-sel.UUCP (Tom Truscott) Newsgroups: net.unix-wizards Subject: Re: fork timing hole? (nope) Message-ID: <355@rti-sel.UUCP> Date: Mon, 19-Aug-85 11:17:53 EDT Article-I.D.: rti-sel.355 Posted: Mon Aug 19 11:17:53 1985 Date-Received: Fri, 23-Aug-85 20:42:44 EDT References: <541@unisoft.UUCP> <671@cyb-eng.UUCP> <546@unisoft.UUCP> Distribution: net Organization: Research Triangle Institute, NC Lines: 17 > ... During a fork the parent does not pass its > pending signals to the child, ... It sure looks like a bug to me. System calls should be atomic actions whenever possible, and we should avoid funny stuff happening 'within' a syscall. I think there are two (at least) fixes to this bug: 1) Copy the appropriate pending signals to the child (simulating delivery *after* the fork is completed). 2) Back out of the fork, deliver the signal, then restart (simulating delivery *before* the fork begins). One detail in copying pending signals to the child is that only signals delivered to the entire process group should be copied. For example, if some process signals the parent with 'kill(parent, SIGINT)' the child should not get it. Tom Truscott