Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!cmcl2!seismo!brl-tgr!tgr!lcc.rich-wiz@locus.ucla.edu From: lcc.rich-wiz@locus.ucla.edu (Richard Mathews) Newsgroups: net.unix-wizards Subject: Re: UNIX question Message-ID: <824@brl-tgr.ARPA> Date: Wed, 18-Dec-85 12:18:07 EST Article-I.D.: brl-tgr.824 Posted: Wed Dec 18 12:18:07 1985 Date-Received: Fri, 20-Dec-85 02:43:33 EST Sender: news@brl-tgr.ARPA Lines: 30 > From: Chris Torek > ... But that is > not all that is amiss. In V7, 3BSD, and 4BSD, and I suspect also > in Sys III and V (and Vr2 and Vr2V2), and probably in V8 as well, > signals are not queued... > The problem is that several children may exit in quick succession. > Only one SIGCLD signal will be delivered, since the parent process > will (just this once) not manage to run before all have exited. > The sigcld handler has no way of determining how many children are > to be processed. In System V, SIGCLDs are queued (well, sort of). See the signal(2) manual page. In reality what Sys V does is this (at least on a VAX): The SIGCLD action gets reset to SIG_DFL when the signal is caught. The signal handler must reestablish itself as the handler for SIGCLD. System V assumes that this is done just before the handler returns. When you call signal(SIGCLD, func), the system checks for any zombies and sends a SIGCLD to the parent if there are any zombie children. Thus it looks as if SIGCLDs are queued (unfortunately, the manual lies and just says "the signal-catching function will be continually reentered until the queue is empty"). Richard M. Mathews Locus Computing Corporation lcc.richard@LOCUS.UCLA.EDU lcc.richard@UCLA-CS {ihnp4,ucivax,trwrb}!lcc!richard {randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard