Re: sigwait - differences between Linux & FreeBSD

[Kostik Belousov]

On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote:

> 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. 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.

[Vlad GALU-2]

On Thu, Oct 8, 2009 at 1:02 PM, Kostik Belousov <kostikbel@...> wrote:

> On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote:
>> 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. 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.
>

This is a bit confusing. sigwait(2) says: "The signals specified by
set should be blocked at the time of the call to sigwait()."...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Kostik Belousov]

On Thu, Oct 08, 2009 at 01:23:37PM +0300, Vlad Galu wrote:

> On Thu, Oct 8, 2009 at 1:02 PM, Kostik Belousov <kostikbel@...> wrote:
> > On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote:
> >> 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. 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.
> >
>
> This is a bit confusing. sigwait(2) says: "The signals specified by
> set should be blocked at the time of the call to sigwait()."...

Blocked and ignored are different attributes of signal.

Ignored means that signal disposition is SIG_IGN, that causes the signal
delivery event to be ignored.

Blocked means that regardeless of signal disposition, signal is not
delivered, but it is recorded somewhere and delivery happen when it
unblocked.

[Jilles Tjoelker]

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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."