Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!mtxinu!rtech!jas
From: jas@rtech.UUCP (Jim Shankland)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: System V and SIGCLD
Message-ID: <453@rtech.UUCP>
Date: Wed, 24-Sep-86 14:53:16 EDT
Article-I.D.: rtech.453
Posted: Wed Sep 24 14:53:16 1986
Date-Received: Thu, 25-Sep-86 03:46:15 EDT
References: <2389@hcrvx2.UUCP> <7396@sun.uucp> <2393@hcrvx2.UUCP> <7561@sun.uucp>
Reply-To: jas@rtech.UUCP (Jim Shankland)
Organization: Relational Technology Inc, Alameda CA
Lines: 27
Xref: mnetor net.unix:5635 net.unix-wizards:7979

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!/