Re: A signal fairy tale

[Christopher Smith <x@xman.org>]

--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel <dank@kegel.com> wrote:
> Once upon a time a hacker named Xman
> wrote a library that used aio, and decided
> to use sigtimedwait() to pick up completion
> notifications.  It worked well, and his I/O
> was blazing fast (since was using a copy
> of Linux that was patched to have good aio).
> But when he tried to integrate his library
> into a large application someone else had
> written, woe! that application's use of signals
> conflicted with his library.  "Fsck!" said Xman.
> At that moment a fairy appeared, and said
> "Young man, watch your language, or I'm going to
> have to turn you into a goon!  I'm the good fairy Eunice.
> Can I help you?"  Xman explained his problem to Eunice,
> who smiled and said "All you need is right here,
> just type 'man 2 sigopen'".  Xman did, and saw:

I must thank the god fair Eunice. ;-) From a programming standpoint, this 
looks like a really nice approach. I must say I prefer this approach to the 
various "event" strategies I've seen to date, as it fixes the primary 
problem with signals, while still allowing us to hook in to all the 
standard POSIX API's that already use signals. It'd be nice if I could pass 
in a 0 for signum and have the kernel select from unused signals (problem 
being that "unused" is not necessarily easy to define), althouh I guess an 
inefficient version of this could be handled in userland.

I presume the fd could be shared between threads and otherwise behave like 
a normal fd, which would be sooooper nice.

I guess the main thing I'm thinking is this could require some significant 
changes to the way the kernel behaves. Still, it's worth taking a "try it 
and see approach". If anyone else thinks this is a good idea I may hack 
together a sample patch and give it a whirl.

Thanks again good fairy Dan/Eunice. ;-)

--Chris