jimr@hcrvx2.UUCP (Jim Robinson) (09/16/86)
* 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). Seems to me this is a handy signal to have as it provides a reasonably elegant means of cleaning up after a process. And, needless to say, more than a few programs will have to be changed, including *shell layers*, when it disappears. [Since the master layer in shell layers cannot remain blocked indefinitely during a 'wait' I would imagine that some kind of polling would be necessary. Gag.] The only other possibility I can think of is that 5.3 has some new and nifty feature that disallows the need for SIGCLD. Comments? J.B. Robinson PS Thanks to all those who answered my query re the IEEE proposal on System V compatible BSD style job control.
guy@sun.uucp (Guy Harris) (09/18/86)
> 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). A little history here. The notion that AT&T is one big happy family when it comes to UNIX is mistaken; there are lots of groups developing applications to run under UNIX, and, like any other bunch of UNIX programmers, they all have their own ideas about what they need to have UNIX do - or, like any other bunch of UNIX programmers, they all have their own ideas about what they *think* they need to have UNIX do. As such, there were at one point probably more variant versions of UNIX inside the Bell System than outside. S5 is the product of an attempt to merge them all into one version. S3 was one step along this path; it picked up a number of features from other versions of UNIX inside Bell, and SIGCLD was probably one of them. The people maintaining S3 may have thought that you could do something better than SIGCLD (the notion that ignoring SIGCLD has the side effect of discarding existing zombies and preventing the creation of new ones is certainly a hack), and wanted to warn that it was only in there for compatibility with other versions of UNIX. At the time, they probably figured there was a good chance that they would get rid of it in favor of something better. Either they still thought so at the time they put out the 5.2 documentation, or nobody had ever bothered to change the documentation. > The only other possibility I can think of is that 5.3 has some new > and nifty feature that disallows the need for SIGCLD. Either you mean "*eliminates* the need for SIGCLD", or "disallows the *use of* SIGCLD." Neither, as far as I know, is true; SIGCLD is still in 5.3. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
chris@pixutl.UUCP (chris) (09/20/86)
In article <2389@hcrvx2.UUCP>, jimr@hcrvx2.UUCP (Jim Robinson) 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). If SIGCLD is gone, does that mean shl is gone too? or, if not, how do the shell layers know a job has terminated? Just wondering... Chris -- Chris Bertin : (603) 881-8791 x218 xePIX Inc. : 51 Lake St : {allegra|ihnp4|cbosgd|ima|genrad|amd|harvard}\ Nashua, NH 03060 : !wjh12!pixel!pixutl!chris
mjp@sfmag.UUCP (M.J.Purdome) (09/21/86)
System V Release 3 has not eliminated SIGCLD. As a matter of fact, the
WARNING section that existed in previous versions of the documentation
has been removed from the SVR3 man page for signal.
The SVID defines 13 signals that are "standard", and it states that specific
implementations may provide implementation-dependent signals. I suppose
this includes SIGCLD as well as SIGPOLL (used with STREAMS) and others
that are not listed in the SVID.
--
Mark Purdome -- AT&T, 190 River Road A-130, Summit, NJ 07901
[ihnp4 | allegra]!attunix!mjp
disclaimer: my opinions != AT&T opinionsjimr@hcrvx2.UUCP (Jim Robinson) (09/23/86)
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). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >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. J.B. Robinson
guy@sun.uucp (Guy Harris) (09/24/86)
> I guess I'll rephrase the question since it hasn't generated quite the > response I had hoped for. The response you had hoped for was an explanation of why SIGCLD disappeared. Since it *didn't* disappear, there is no chance of getting quite that response. > 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 is not there. It is in the S5 documentation (and, as pointed out, the "this may disappear evenutally" note disappeared in S5R3), but it's not in the SVID. The SVID != the System V documentation. > 2) Assuming the latter, does this not mean that there is no requirement > for a SVID adhering UNIX to include SIGCLD? Yes. > 3) If so, what gives? As has been pointed out, at least a couple of > important programs are going to break? So? Just don't run those programs on a SVID-compliant system unless you've verified that that system also supports SIGCLD. There is also no requirement that a SVID-compliant system implement the routines in the "-lPW" library, either, and this may break some programs. A SVID-COMPLIANT SYSTEM IS NOT REQUIRED TO BE ABLE TO RUN EVERY PROGRAM EVER WRITTEN FOR SYSTEM V. It is not even required to be able to run every program whose source is shipped with System V. That's why it's called an "interface definition"; a SVID-compliant system is required to be able to run every valid program written using the SVID. The SVID defines an interface, and people write programs to use that interface. Some programs that come with System V are not written strictly for that interface. As such, they may not run on all SVID-compatible systems. Consider SIGCLD to be an extension to UNIX, provided by certain systems, rather than as part of the core of UNIX. There's nothing wrong with that system also providing an "init", or "shl", or whatever, that uses that extension. If another system doesn't have that extension, it'll have to do things differently. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
SofPasuk@imagen.UUCP (09/24/86)
> 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). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >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!)
jas@rtech.UUCP (Jim Shankland) (09/24/86)
Guy Harris writes:
Just don't run programs [needing the SIGCLD signal] on a SVID-compliant
system unless you've verified that that system also supports SIGCLD.
A SVID-COMPLIANT SYSTEM IS NOT REQUIRED TO BE ABLE TO RUN EVERY PROGRAM
EVER WRITTEN FOR SYSTEM V. It is not even required to be able to run
every program whose source is shipped with System V. That's why it's
called an "interface definition"; a SVID-compliant system is required
to be able to run every valid program written using the SVID. The SVID
defines an interface, and people write programs to use that interface.
Consider SIGCLD to be an extension to UNIX, provided by certain systems,
rather than as part of the core of UNIX.
All true, but SIGCLD is an awfully useful piece of UNIX to be leaving out
of SVID, especially when there is no persuasive reason to leave it out
(unlike shared memory, for example, which is hard to implement on
a loosely coupled multiprocessor such as the CT Megaframe). If the
interface definition is unnecessarily restrictive, it loses some of
its usefulness, since it is likely to be extended in non-standard ways
(Pascal comes to mind).
--
Jim Shankland
..!ihnp4!cpsc6a!\
rtech!jas
..!ucbvax!mtxinu!/brett@wjvax.UUCP (Brett Galloway) (09/26/86)
In article <453@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: >Guy Harris writes: > > Just don't run programs [needing the SIGCLD signal] on a SVID-compliant > system unless you've verified that that system also supports SIGCLD. > > A SVID-COMPLIANT SYSTEM IS NOT REQUIRED TO BE ABLE TO RUN EVERY PROGRAM > EVER WRITTEN FOR SYSTEM V. It is not even required to be able to run > every program whose source is shipped with System V. That's why it's > called an "interface definition"; a SVID-compliant system is required > to be able to run every valid program written using the SVID. The SVID > defines an interface, and people write programs to use that interface. > > Consider SIGCLD to be an extension to UNIX, provided by certain systems, > rather than as part of the core of UNIX. > >All true, but SIGCLD is an awfully useful piece of UNIX to be leaving out >of SVID, especially when there is no persuasive reason to leave it out >(unlike shared memory, for example, which is hard to implement on >a loosely coupled multiprocessor such as the CT Megaframe). If the >interface definition is unnecessarily restrictive, it loses some of >its usefulness, since it is likely to be extended in non-standard ways >(Pascal comes to mind). Here here! Standards definitions can fail in one of two ways. The first is making the standard unnecessarily generous in features (e.g. ada). This makes applications difficult to port because the intended environment to port to may not have implemented a feature needed by the application. The second failure is making the standard unnecessarily miserly in features (e.g. the SVID with respect to SIGCLD). This makes applications difficult to port because each implementation of the standard is likely to extend it in its own way to provide useful functionality. To be useful and portable, the standard must strike the golden mean. I have not read the SVID, but the omission of SIGCLD leads me to believe that the authors of SVID inclined to the latter error. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett