Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shelby!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.internals
Subject: Re: Signals queued or not? (POSIX note)
Message-ID: <10150@dog.ee.lbl.gov>
Date: 22 Feb 91 15:49:02 GMT
References: <7103@fs1.cam.nist.gov> <67880001@hpcupt1.cup.hp.com> <2519@inews.intel.com> <10007@dog.ee.lbl.gov> <8699@lynx.UUCP>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 36
X-Local-Date: Fri, 22 Feb 91 07:49:02 PST

[I wrote: Signals are not queued.]

In article <8699@lynx.UUCP> bog@lynx.uucp (Bill O. Gallmeister) writes:
>While this is correct for most currently existing UNIXes, note that:
>
>(1) POSIX 1003.1 allows signals to be queued ...

This is probably a mistake, but then POSIX is not Unix....

>(2) POSIX 1003.4 Draft 10 specifies Real-Time Extended Signals, a range
>of signal numbers that _are_ queued.

This is *definitely* a mistake.

While I will not argue that `interrupt style' signals are the One True
Correct Way---indeed, I believe (without supportive arguments, and not
strongly enough to try it out; this is just `gut feel') that queued
signals would have been better---I am quite certain that mixing queued
and interrupt-style signals is a disaster.  The two are completely
different things, and should use a different implementation.

(In other words, if you are going to add analogues to signals, but which
are queued, you should NOT call them `signals', and you should not use
`signal system calls' to manipulate them.)

>Caveats/Asides:
>1003.1 is an ISO standard.  1003.4 is being balloted.  Whether POSIX is
>UNIX is a matter of debate.  But there are UNIX systems that queue signals.

I think the debate can be ended by pointing out that a POSIX implementation
that returns errors for practially every operation is conformant (useless,
but conformant).  And I will continue to claim that signals are not queued
---if what you have is queued, it is not a signal.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov


Brought to you by Super Global Mega Corp .com