On Tue, Jan 14, 2014 at 8:10 AM, Benjamin Shadwick <benshadwick@gmail.com>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_se...), 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.