Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site hpfcls.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hpfcdc!hpfcls!hpfcla!rml
From: rml@hpfcla.UUCP
Newsgroups: net.unix-wizards
Subject: Re: fork timing hole???...
Message-ID: <132000018@hpfcls.UUCP>
Date: Thu, 22-Aug-85 14:01:00 EDT
Article-I.D.: hpfcls.132000018
Posted: Thu Aug 22 14:01:00 1985
Date-Received: Wed, 28-Aug-85 21:04:48 EDT
Organization: 22 Aug 85 12:01:00 MDT
Lines: 51

>         In 3) the signal arrives between when the parent shell enters fork()
> and the new process is created (specifically before its process group is
> filled in in its proc entry). 
> 
> The main reason for this is that newproc() doesn't copy pending signals from
> the parents proc entry to the child.
> 
> Finally, my question ..... Is this a bug??

It does seem like a bug, although a rather minor one in practice.  In
the scenario you give, when the window is hit, most likely either

	a) the command which wasn't killed completes and the user
	   doesn't mind
or
	b) the user hits the interrupt key again to kill it.

Since there we're dealing with human reaction times here, there doesn't
seem to be any real harm done.  In a similar scenario with another
process sending a signal to the process group with kill(2), the bug
might be more severe.

> And the next, as yet unanswered question .... Should children inherit pending
> signals?? .... Will it do any harm??

No, I don't think children should inherit pending signals.  In this
particular case the signal was sent to the entire process group, and
thus it could be interpreted as being intended for the child as well.
However, ALL pending signals can include signals which have been
specifically sent to the parent process by kill(2).  If the child
inherited signals we would again have three possible situations:

	1) parent receives signal before fork
	2) parent receives signal after fork
	3) parent and child both receive signal

with the third being an anomaly caused by hitting a small window.  The
kernel currently has no way to distinguish signals sent to an individual
process from those sent to a process group (or to pid -1).  I suppose
such a mechanism could be added and the appropriate signals could be
passed across forks, but I'm not sure it would be worthwhile.

Also, inheriting signals across forks would have more impact on systems
which allow masking of signals (mainly 4.2 and those with signal
mechanisms based on 4.2).  On those systems the set of pending signals
is not limited to those arriving in the small window during fork.  It
could be argued that this would provide more correct semantics, but it's
not compatible with existing systems.

			Bob Lenk
			{hplabs, ihnp4}!hpfcla!rml