Re: A signal fairy tale

Balbir Singh (balbir.singh@wipro.com)
Wed, 27 Jun 2001 11:51:36 +0530 (IST)


Shouldn't there be a sigclose() and other operations to make the API
orthogonal. 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.

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).

Let me know, when somebody has a patch or needs help, I would like to
help or take a look at it.

Balbir

|NAME
| sigopen - open a signal as a file descriptor
|
|SYNOPSIS
| #include <signal.h>
|
| int sigopen(int signum);
|
|DESCRIPTION
| The sigopen system call opens signal number signum as a file descriptor.
| That signal is no longer delivered normally or available for pickup
| with sigwait() et al. Instead, it must be picked up by calling
| read() on the file descriptor returned by sigwait(); the buffer passed to
| read() must have a size which is a multiple of sizeof(siginfo_t).
| Multiple signals may be picked up with a single call to read().
| When that file descriptor is closed, the signal is available once more
| for traditional use.
| A signal number cannot be opened more than once concurrently; sigopen()
| thus provides a way to avoid signal usage clashes in large programs.
|
|RETURN VALUE
| signal returns the new file descriptor, or -1 on error (in which case, errno
| is set appropriately).
|
|ERRORS
| EWOULDBLOCK signal is already open
|
|NOTES
| read() will block when reading from a file descriptor opened by sigopen()
| until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called
| to set it into nonblocking mode.
|
|HISTORY
| sigopen() first appeared in the 2.5.2 Linux kernel.
|
|Linux July, 2001 1
|

-
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/