Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: No more signals
Message-ID: <6027@brl-smoke.ARPA>
Date: Thu, 25-Jun-87 09:32:26 EDT
Article-I.D.: brl-smok.6027
Posted: Thu Jun 25 09:32:26 1987
Date-Received: Sat, 27-Jun-87 01:24:51 EDT
References: <48300005@hcx1> <1714@munnari.oz> <492@its63b.ed.ac.uk>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 12

In article <492@its63b.ed.ac.uk> simon@its63b.ed.ac.uk (Simon Brown) writes:
>If I send 5 SIGINT signals to a
>process, there is no guarentee that that process will receive them all ...

This is a good point; per-signal counters would be best.  One would also
need a way to reset (flush) the counter for a signal.  Once you start
taking care of things like this, you end up implementing something very
much like System V semaphore IPC.

Signals were originally intended as a way to abnormally change the flow
of execution of a UNIX process.  Trying to press them into service for
general IPC will probably result in a suboptimal design.