sigwait - differences between Linux & FreeBSD

Jilles Tjoelker jilles at
Fri Oct 9 18:43:11 UTC 2009

On Thu, Oct 08, 2009 at 01:02:09PM +0300, Kostik Belousov wrote:
> On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote:
> > In my efforts to make the xrdp port more robust under FreeBSD, I have
> > discovered that sigwait (kind of an analogue to select(2), but for
> > signals rather than I/O) re-enables ignored signals in its list under
> > Linux, but not FreeBSD. The sesman daemon uses SIGCHLD to clean up
> > after a session has exited. Under Linux this works OK, under FreeSBD
> > it doesn't. I have worked around it in a very hackish manner (define a
> > dummy signal handler and enable it using signal, which means that the
> > sigwait call can then be unblocked by it), but am wondering if anyone
> > else has run across the same problem, and if so, if they fixed it in
> > an elegant manner. Also, does anyone know the correct semantics of
> > sigwait under this situation?

> ports@ is the wrong list to discuss the issue in the base system.

> Solaris 10 sigwait(2) manpage says the following:
> If sigwait() is called on an ignored signal, then the occurrence of the
> signal will be ignored, unless sigaction() changes the disposition.

> We have the same behaviour as Solaris, ingored signals are not queued or
> recorded regardeless of the presence of sigwaiting thread.

POSIX permits both behaviours here: a blocked and ignored signal may or
may not be discarded immediately on generation. Making this depend on
whether there is a sigwaiting thread seems broken, and I don't think
Linux does that.

I think your "very hackish" approach is correct: set up a dummy signal
handler after blocking the signal. 

Additionally, POSIX requires applications to set the SA_SIGINFO flag if
they want queuing. This applies even if the signals are blocked and
received using sigwaitinfo(2) or sigtimedwait(2). The SA_SIGINFO flag
can only be set by setting a handler using sigaction(2). (Note, this
does not mean that all signals are queued if SA_SIGINFO is set. It means
that signals may not be queued if SA_SIGINFO is not set.)

Jilles Tjoelker

More information about the freebsd-hackers mailing list