Date: Fri, 9 Oct 2009 20:43:09 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Stephen Hocking <stephen.hocking@gmail.com> Cc: ports@freebsd.org, Kostik Belousov <kostikbel@gmail.com>, hackers@freebsd.org Subject: Re: sigwait - differences between Linux & FreeBSD Message-ID: <20091009184309.GA15210@stack.nl> In-Reply-To: <20091008100209.GG2259@deviant.kiev.zoral.com.ua> References: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com> <20091008100209.GG2259@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091009184309.GA15210>