System V and SIGCLD
SofPasuk at imagen.UUCP
SofPasuk at imagen.UUCP
Thu Sep 25 00:55:50 AEST 1986
> 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).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >Geez, youngsters these days have no sense of history; they probably think
> >"AT&T UNIX" started with System V. Mutter, mutter. :-)
> >
> >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).
>
> I guess I'll rephrase the question since it hasn't generated quite the
> response I had hoped for.
>
> 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)
>
> 2) Assuming the latter, does this not mean that there is no requirement
> for a SVID adhering UNIX to include SIGCLD?
>
> 3) If so, what gives? As has been pointed out, at least a couple of
> important programs are going to break?
>
> 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.
I couldn't find SIGCLD in SVID either. The only means in SVID to detect the
completion of a child process seems to be via WAIT, i.e. a planned, synchronous
activity on the part of a program as opposed to an interrupt.
I second the request that some RESPONSIBLE party from the American Telephone &
Telegraph Corporation who is DIRECTLY INVOLVED with SVID directly respond to
this issue. (Please no flames about whose UNIX is better or whose long distance
service is better or who makes better switchboards!)
More information about the Comp.unix.wizards
mailing list