On Tue, 3 Dec 2002, Noriyuki Soda wrote:

> >>>>> On Mon, 2 Dec 2002 22:24:39 -0600,
> 	Juli Mallett <jmallett@NewGold.NET> said:
>
> > So essentially you don't want reliable signals, right?
>
> Well, historically, the word "reliable signal" means avoiding
> race condition about signal handling. The signal system we
> have now is already reliable in that sense (since 4.2BSD).
>
> Of course, what you mean in this context is different from above.
> To answer your question, yes, I don't need signal queueing for
> non-realtime signals. But please don't confuse me, I say we need
> signal queueing for realtime signals, because realtime API in
> POSIX needs signal queueing. And that is also the reason that I want
> to avoid signal queueing for non-realtime signals, queueing
> non-realtime signal takes kernel resource away from realtime signals.
>
> Why do you want signal queueing for non-realtime signals?
> Is there any application which wants such behaviour?
> Is such application really portable?
> (See the article posted by Giles Lean.)

My understanding was that Juli is suggesting a signal queue of length
"one" for non-realtime signals using a generalized mechanism for all
signal handling.  So, if we set aside realtime signals, because everyone
is in agreement on how to handle them, what are the pros and cons of
sticking with the conventional signal mechanism vs Juli's signal queues
of length one?

Admittedly, as a curious novice, I've no clue what it would take to
implement in terms of memory or computation resources, maybe it really
/is/ a bad idea, but I definitely think the notion of having a
generalized signal mechanism is a nice one--as long as it's not
expensive in terms of kernel resources or otherwise flawed.  And I think
it'd be worthwhile to run some "back of the envelope" numbers to figure
out if Juli's idea actually /would/ use excessive kernel resources
before it is summarily dismissed.

At the very least, I'd find it educational to see the idea picked apart
to have its weaknesses exposed in more quantifiable terms than have thus
far been offered.

-brian.