Perry E. Metzger wrote:
> > http://www.hpl.hp.com/techreports/2000/HPL-2000-174.pdf
> 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.

That paper is still interesting. Their test code could be used
to benchmark and tune RT signal implementation once finished :)
Provided it's available somewhere, of course.

> You really want mechanisms like kqueue, which we're adding.

Yeah, kqueue is superiour to both select(2)/poll(2) solution
and RT signals. Too bad it's still on branch only.

> RT signals suck. We should add them, though, for API compatibility
> with software that needs them.

Like linuxthreads :)

Really, having support for RT signals is needed for more than just
API compatibility. It's pretty much required building block for
other, more useful POSIX.4 RT extensions, like AIO or message
queues.  There are places where RT signals are clear win, compared
with 'classic' unreliable context-free signals at least.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=  Those who would give up liberty for a little temporary safety deserve  =-
-=  neither liberty nor safety, and will lose both.  -- Benjamin Franklin  =-