1

即使我阻止了这些信号,我的应用程序有时也会从 SIGIO 或 SIGUSR1 信号终止。

我的主线程从阻塞 SIGIO 和 SIGUSR1 开始,然后进行 2 次 AIO 读取操作。这些操作使用线程来获取有关操作状态的通知。通知函数(作为分离线程调用)启动另一个 AIO 操作(它们操作已读取的数据并开始将其写回文件)并通过发送信号来处理通知(一个操作使用 SIGIO,另一个使用 SIGUSR1)到这个过程。我通过在主线程中调用 sigwait 来同步接收这些信号。不幸的是,有时我的程序崩溃,被 SIGUSR1 或 SIGIO 信号(应该被 sigmask 阻止)停止。

一种可能的解决方案是为它们设置 SIG_IGN 处理程序,但这并不能解决问题。不应调用它们的处理程序,而应在主程序循环的下一次迭代中通过 sigwait 从挂起的信号中检索它们。

我不知道哪个线程以这种方式处理这个信号。也许是 init 接收到这个信号?还是一些壳线?我不知道。

4

1 回答 1

1

我冒昧地猜测信号正在由您的 AIO 回调线程之一或由生成信号的线程接收。(证明我错了,我会删除这个答案。)

不幸的是,根据标准,“[a SIGEV_THREAD] 线程的信号掩码是实现定义的。” 例如,在 Linux (glibc 2.12) 上,如果我在 中阻止 SIGUSR1 main,然后设法从aio_read调用中运行 SIGEV_THREAD 处理程序,则处理程序在 SIGUSR1 未阻塞的情况下运行。

这使得 SIGEV_THREAD 处理程序不适合必须可靠且可移植地处理信号的应用程序。

于 2015-12-14T22:27:35.383 回答