Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!dual!ptsfa!qantel!ihnp4!cbatt!cbuxc!cbuxb!cbrma!karl From: karl@cbrma.UUCP (Karl Kleinpaste) Newsgroups: net.unix-wizards Subject: Re: System V and SIGCLD Message-ID: <5174@cbrma.UUCP> Date: Wed, 24-Sep-86 09:39:33 EDT Article-I.D.: cbrma.5174 Posted: Wed Sep 24 09:39:33 1986 Date-Received: Thu, 25-Sep-86 07:58:07 EDT References: <2389@hcrvx2.UUCP> <7396@sun.uucp> <2393@hcrvx2.UUCP> Organization: AT&T-BL, RMAS, Columbus Lines: 51 jimr@hcrvx2.UUCP (Jim Robinson) writes: >In article <7396@sun.uucp> guy@sun.uucp (Guy Harris) writes: >>> Can anyone explain AT&T's rationale in dropping SIGCLD? In my 5.2 >>> manual there is a warning "strongly" discouraging its use in >>> new programs, and there is no mention of it anywhere in the System V >>> Interface Definition (at least I couldn't find any). >> >>The System III documentation has much the same warning; it came out in 1980, >>so fi they haven't dropped it by now, I suspect they're not going to >>(especially since things like "init" use it as well). > >1) I could not find any mention of SIGCLD in the System V Interface > Definition. Is this because I missed it, or is it because it just > ain't there? (It certainly is not mentioned with the other signals > in the section dealing with the 'signal' service routine) It's not there. Not in my copy, anyway, from Spring 1985. That fact notwithstanding, notice that neither are SIGIOT, SIGEMT, SIGBUS, or SIGSEGV. I have my doubts that they'll go away any time soon. What would application development in a UNIX environment be like without the ever-entertaining comment, "Segmentation violation - core dumped"? Of course "init" could be hacked so that it no longer utilized SIGCLD. But then "init" wouldn't have had new code put into it to handle SIGCLD if it weren't considered important, especially with that warning present. >2) Assuming the latter, does this not mean that there is no requirement > for a SVID adhering UNIX to include SIGCLD? Um..."requirement" in a technical or political sense? Technically, SIGCLD could be missing from Sys5.N (N>3) just because somebody's mood was bad the day such a decision had to be made. Politically, there would be hell to pay if it were taken out without a darn good replacement strategy for asynchronous notification of child death. >3) If so, what gives? As has been pointed out, at least a couple of > important programs are going to break? Guy's right - it's going to stay. It would break a non-trivial amount of code (nobody really *wants* to hack up "init" again), and it's a useful feature; I use it quite a lot, in a job control emulation. >It would be especially pleasant if someone from AT&T could take the >time to fire in a quick response since they are in the best position >of knowing what the story is wrt the SVID and SIGCLD. Right, here's a disclaimer: I work for AT&T-BL, but I have no work-related connections with the folks who make decisions like that. -- Karl Kleinpaste