Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!caip!lll-crg!gymble!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix-wizards Subject: Re: UNIX question Message-ID: <2597@umcp-cs.UUCP> Date: Wed, 18-Dec-85 21:57:14 EST Article-I.D.: umcp-cs.2597 Posted: Wed Dec 18 21:57:14 1985 Date-Received: Fri, 20-Dec-85 05:08:40 EST References: <824@brl-tgr.ARPA> Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 30 In article <824@brl-tgr.ARPA> lcc.rich-wiz@locus.ucla.edu (Richard Mathews) writes: >> From: Chris Torek >> 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... > 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): [description deleted] In other words, System V arranges for the delivery of a SIGCLD, in the process changing things back to SIG_DFL, so that that exactly one is sent, and one more will be sent when the signal handler restores SIGCLD catching if and only if there is at least one more child process. To put it another way, the signals themselves are not queued, but child process exit is not the only trigger for SIGCLD; exited children are already queued, so the effect is the same. Implemented properly, that will guarantee reliable operation. Ok. One down, 31 to go :-). ---Signals, of course. What else? (Well, all right, I will give them credit for not breaking everything in the name of advancement.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu