[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A signal fairy tale
Balbir Singh <> wrote:

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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.041 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site