Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.9 3/12/85; site unisoft.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!lll-crg!dual!unisoft!pc
From: pc@unisoft.UUCP (Paul Campbell)
Newsgroups: net.unix-wizards
Subject: fork timing hole ???...
Message-ID: <541@unisoft.UUCP>
Date: Wed, 14-Aug-85 20:15:58 EDT
Article-I.D.: unisoft.541
Posted: Wed Aug 14 20:15:58 1985
Date-Received: Sun, 18-Aug-85 03:02:55 EDT
Distribution: net
Organization: UniSoft Systems, Berkeley
Lines: 55

<oog>

	The Scenario
	------------

You type

	"ls<ret><del>"

Where <del> is the interrupt key of choice and the space between <ret> and <del>
is very fast (try two fingers poised for action).

What happens? 1 of 3 things

1) 

$ ls

$

2)

$ ls
$

3)

$ ls
my
local
files
$

BTW this has been repeated on several System 5/5.2 boxes as well as
4.1on a Vax  (4.2 is not available here). It would probably be hard
to reproduce on a Cray ... unless you have REALLY fast fingers.

In 1) ls (or its shell prior to execing) was forked and then received the
signal and died. In 2) the parent shell received the signal prior to calling
fork(). 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??

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



		Paul Campbell
		..!ucbvax!unisoft!paul