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 回答