Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: net.unix-wizards
Subject: Re: System V and SIGCLD
Message-ID: <630005@hpfcdc.HP.COM>
Date: Fri, 26-Sep-86 15:32:37 EDT
Article-I.D.: hpfcdc.630005
Posted: Fri Sep 26 15:32:37 1986
Date-Received: Thu, 2-Oct-86 20:51:06 EDT
References: <2389@hcrvx2.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 24

> 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).

I would speculate that it was left out because of a desire not to
standardize some of the specific semantics SICLD has in System V
implementations.  In particular, many people are not fond of the
side-effect that setting SIGCLD to SIG_IGN has on wait(2).  Also, the
precise semantics of how SIGCLD is "queued" do not agree between System
V documentation and implementation, so there could be disagreement on
what to standardize.

>                                                              If the
> interface definition is unnecessarily restrictive, it loses some of
> its usefulness, since it is likely to be extended in non-standard ways

That's certainly a valid point which needs to be traded off against
the risk of standardizing the "wrong" feature, thus either perpetuating
that feature or reducing acceptance of the standard.  I make no
judgement as to whether AT&T made the correct tradeoff in this case.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml