Messages in this thread | | | Date | Wed, 27 Jun 2001 19:49:19 -0700 (PDT) | From | "Daniel R. Kegel" <> | Subject | Re: A signal fairy tale |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |