Date: Thu, 08 Oct 2009 13:38:16 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: Stephen Hocking <stephen.hocking@gmail.com> Cc: ports@freebsd.org Subject: Re: sigwait - differences between Linux & FreeBSD Message-ID: <4ACDCF28.6040807@gmx.de> In-Reply-To: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com> References: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Hocking schrieb:
> Hi all,
>
> 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.
If the application relies on sigwait() to wait for and extract an ignored signal
(SIG_IGN), it is non-portable, as it expects non-POSIX semantics, and should be
fixed by the upstream maintainer (I haven't checked that).
Note: Linux has the same semantics, quoting its manual page (on Ubuntu 9.10 beta):
sigwait suspends the calling thread until one of the signals in set is
delivered to the calling thread. It then stores the number of the sig‐
> nal received in the location pointed to by sig and returns. The signals
> in set must be blocked and not ignored on entrance to sigwait. If the
delivered signal has a signal handler function attached, that function
is not called.
> The sesman daemon uses SIGCHLD to clean up after a session has exited. Under
> Linux this works OK, under FreeSBD it doesn't.
Not sure I understand. How can it clean up if it's not made aware of child's
termination? Or do some Linux kernels behave in another way?
Setting SIGCHLD to SIG_IGN (default) means that the kernel will let go of the
child processes as they exit, rather than turn them into zombies. You cannot
wait() for them though.
> 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?
That is not a hackish workaround, but one of the few safe ways to sigwait() for
SIGCHLD. A version fixed thus should still work on Linux, so that fix should be
made by xrdp upstream.
The canonical reference would be the POSIX standard (IEEE Std 1003.1).
2008: http://www.opengroup.org/onlinepubs/9699919799/
2001, 2004 edition: http://www.opengroup.org/onlinepubs/000095399/
The latter is also known as the Single Unix Specification v3 (SUSv3).
HTH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ACDCF28.6040807>