Re: A signal fairy tale

[Jamie Lokier]

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