System V and SIGCLD

[Karl Kleinpaste]

jimr at hcrvx2.UUCP (Jim Robinson) writes:
>In article <7396 at sun.uucp> guy at 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