Signals queued or not? (POSIX note)

[Chris Torek]

[I wrote: Signals are not queued.]

In article <8699 at lynx.UUCP> bog at 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 at ee.lbl.gov