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!linus!philabs!prls!amdimage!amdcad!amd!vecpyr!lll-crg!dual!unisoft!pc From: pc@unisoft.UUCP (Paul Campbell) Newsgroups: net.unix-wizards Subject: Re: fork timing hole? (nope) Message-ID: <546@unisoft.UUCP> Date: Fri, 16-Aug-85 16:27:24 EDT Article-I.D.: unisoft.546 Posted: Fri Aug 16 16:27:24 1985 Date-Received: Tue, 20-Aug-85 07:01:42 EDT References: <541@unisoft.UUCP> <671@cyb-eng.UUCP> Distribution: net Organization: UniSoft Systems, Berkeley Lines: 21 > Explanation: If you look closely at the sh/csh code, you'll find cases > where sh and/or csh catch SIGINT and emit a newline. Specifically, it's > the parent shell which does this if it's interrupted while waiting for > the child to terminate. By the way, receipt of the interrupt character > generates a SIGINT for every process in the controlling terminal's > process group. > > > ... [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. During a fork the parent does not pass its pending signals to the child, if an interrupt character is received after the shell starts the fork call (enters kernel mode) and before the system writes the process group in the proc table entry then the new process does not belong to the parent's process group until this moment. During this time any signals to the parent will not be received by the child. Paul Campbell ..!ucbvax!unisoft!paul