Messages in this thread | | | Date | Wed, 27 Jun 2001 11:18:28 +0200 | From | Jamie Lokier <> | Subject | Re: A signal fairy tale |
| |
Dan Kegel wrote: > 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).
Does this mean that the read() call must write sizeof(siginfo_t) bytes for each signal delivered?
At the moment, the kernel does not have to write the whole siginfo_t structure to userspace -- it can write just those fields which are relevant for a particular signal.
> A signal number cannot be opened more than once concurrently; > sigopen() thus provides a way to avoid signal usage clashes in > large programs.
sigopen() won't prevent signal usage clashes if the other user is using sigaction() and sigtimedwait(), or will it?
Btw, this functionality is already available using sigaction(). Just search for a signal whose handler is SIG_DFL. If you then block that signal before changing, checking the result, and unblocking the signal, you can avoid race conditions too. (This is what my programs do).
-- Jamie - 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/
| |