Re: A signal fairy tale

["Daniel R. Kegel" <dank@alumni.caltech.edu>]

Balbir Singh <balbir.singh@wipro.com> wrote:

>Shouldn't there be a sigclose() and other operations to make the API
>orthogonal.

No, plain old close() on the file descriptor returned by sigopen()
would do the trick.

>sigopen() should be selective about the signals it allows
>as argument. Try and make sigopen() thread specific, so that if one
>thread does a sigopen(), it does not imply it will do all the signal
>handling for all the threads.

IMHO sigopen()/read() should behave just like sigwait() with respect 
to threads.  That means that in Posix, it would not be thread specific,
but in Linux, it would be thread specific, because that's how signals
and threads work there at the moment.

>Does using sigopen() imply that signal(), sigaction(), etc cannot be used.
>In the same process one could do a sigopen() in the library, but the
>process could use sigaction()/signal() without knowing what the library
>does (which signals it handles, etc).

Between sigopen() and close(), calling signal() or sigaction() on that 
signal would probably return EBUSY.   A well-behaved program already
looks for an unoccupied signal using sigaction (as Jamie Lokier
points out), so they shouldn't try to reuse a signal in use by sigopen().

- Dan