[asio-users] [Asio] signal_set not blocking/queueing signals on shutdown

[Benjamin Shadwick]

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.

[Slava]

On Wed, 15 Jan 2014 19:01:56 +0100, Benjamin Shadwick

On Tue, Jan 14, 2014 at 8:10 AM, Benjamin Shadwick

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.

I first hear about asio signals, but I believe purpose of these signal
facility in asio is only to help you to implement *waiting* for signals,
like SIGCHLD, or SIGUSR{12}, whateverer you may choose for your IPC
communication. You should not misuse asio for general signal handling.
Normally signals are instantaneous things to be delivered right now right
here without any regard in which state the target is.

Regards, Slava