所以我有一个可以使用SIGQUIT正常关闭的守护进程。
该守护程序正在运行boost::asio::io_service。我用boost::asio::signal_set来捕捉这个信号。
我遇到了一种我认为完全错误的行为。当我销毁boost::asio::signal_set对象时，它不会恢复该信号的先前处理程序。 SIGQUIT的前一个处理程序是无操作。因此，在boost::asio::signal_set被销毁后收到此信号后，我的守护程序终止。我的猜测是因为boost::asio::signal_set在破坏时设置了默认处理程序，即终止程序，而不是先前的处理程序。
我觉得这很不合适。我问的是我错了吗？也许我错过了什么？
答案 0 :(得分：1)
Boost.Asio没有为已添加到boost::asio::signal_set然后通过signal_set::remove()，signal_set::clear()或{{1}的销毁删除的信号指定生成的处理程序状态}}。特别是，没有为Signal Set Service requirements中的任何关联操作指定后置条件。
快速浏览signal_set_service::add() implementation：
signal_set和signal_set_service::clear() implementation：
::sigaction(signal_number, &sa, 0)
显示对sigaction()的调用未处理以前安装的处理程序，并导致在通过struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_DFL;
::sigaction(reg->signal_number_, &sa, 0)
删除信号时注册默认处理程序操作。
由于信号可能在Boost.Asio将信号操作设置为默认值后传递，但在应用程序代码能够分配其自己的处理程序之前，请考虑使用pthread_sigmask()来阻止{{1}内的所有信号}}。从signal_set_service移除信号后，通过io_service分配所需的处理程序，然后取消阻止信号。
以下是演示此方法的完整示例：
signal_set及其输出：
sigaction()