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