In message <87itdeq9nc.fsf@snark.piermont.com>, you write: 

-> Mike Cheponis <mac@Wireless.Com> writes:
-> > Interesting paper here:
-> > 
-> > http://www.hpl.hp.com/techreports/2000/HPL-2000-174.pdf
-> > 
-> > It measures linux, but draws some conclusions about how RT signals provide
-> > reduced server complexity, increased robustness under high load, and
-> > potentially increased throughput.
-> > 
-> > I apologize in advance if all this is already well-known.
-> 
-> There is much better literature out there, most of which says real
-> time signals are a very bad lose, and reduce robustness. See, for
-> example, some excellent papers on the subject done by Niels Provos.
-> 
-> You really want mechanisms like kqueue, which we're adding. RT signals
-> suck. We should add them, though, for API compatibility with software
-> that needs them.

One of the real practical ways in which RT signals suck is the fact that
your signal queue can overflow and the amount of code/pain to deal with
recovering from this condition is about as large as the rest of the code
that actually does Real Work.  Moreover, the recovery code is always the
buggiest, because it's not in the `expected' flow of code 8-)

Been there, done that, don't wear that T-shirt.

--rafal

----
Rafal Boni                                                  rafal@mediaone.net