Re: [Boost-users] [Asio] signal_set not blocking/queueing signals on shutdown

Subject: Re: [Boost-users] [Asio] signal_set not blocking/queueing signals on shutdown
From: Benjamin Shadwick (benshadwick_at_[hidden])
Date: 2014-01-15 13:01:56

On Tue, Jan 14, 2014 at 8:10 AM, Benjamin Shadwick <benshadwick_at_[hidden]>wrote:

> I've written an io_service+signal_set signal handling implementation in a
> thread of my application that triggers an orderly shutdown when (among
> other things) the user presses Ctrl+C.
>
> According to the Boost.Asio documentation for signal_set (
> http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/signal_set.html), just having a signal_set (with inherent dependency on an io_service)
> with registered signals and not in a wait state is supposed to be enough to
> cause signals to be blocked/queued.
>
> After I stop the io_service and cancel the wait state on the signal_set,
> however, it appears that signal blocking/queueing is no longer occurring. I
> say this because hitting Ctrl+C during orderly shutdown after the
> io_service has stopped causes my application to instantly terminate (and in
> one case generate a core file).
>
> Is there something about stopping the io_service and/or canceling the
> async wait on the signal_set that is causing the note about signal queueing
> in the signal_set documentation to no longer apply?
>
> Thanks in advance.
>

Update:

I've also noticed that signals are not being completely blocked at
startupbetween the time that the signal_set is configured and the time
that I call
run() on the io_service, as holding down Ctrl+C just after adding signals
to the signal_set often causes my XML parser to run off the rails (throws
exceptions about failing to open files for some unspecified reason).

I've implemented POSIX-level explicit signal blocking in the main thread
and unblocking in the io_service thread using pthread_sigmask() and
friends, and this works much, much better. This is not a completely
satisfactory solution, though, as it is likely to create portability
problems for my colleagues who are currently attempting to produce a
Windows port of our application.

The only issue I'm still seeing is that starting to hold down Ctrl+C just
after the signal_set is configured occasionally results in my signal
handler being called a bunch of times with the boost::system::error_code
parameter not set *and* the signal number set to *zero* as soon as the
io_service
is started. While I expected the Ctrl+C's to cause signals to be queued and
then delivered when the io_service starts, I'm confused that
Boost.Asioisn't providing either a useful error code or a useful
signal number when
calling my signal handler.