linux - signalfd 和 sigaction 之间可以竞争吗？

Question

为特定信号指定处理程序的经典方法是通过 sigaction。 Linux 还提供了 signalfd 功能，我们可以在其中将信号连接到文件描述符，然后将 select/(e)poll 应用于该描述符，这非常适合许多事件循环驱动系统的概念。

我想知道当两种机制发生冲突时会发生/应该发生什么。可以有竞争条件吗？在 signalfd 联机帮助页 ( http://man7.org/linux/man-pages/man2/signalfd.2.html ) 上，我们读到:

Normally, the set of signals to be received via the file descriptor should be blocked using sigprocmask(2), to prevent the signals being handled according to their default dispositions.

因此，它说“通常”我们使用信号掩码以防止(默认)处理程序处理信号。它并没有说当我们有一个文件描述符连接到它时，我们必须阻止该信号。不幸的是，手册页没有具体说明当我们不阻止信号时会发生什么。

这看起来像是定义不明确的行为。我不相信这实际上没有明确定义，并且想知道这里是否有人知道i)我能找到关于系统应该如何运行的详细规范或ii ) 它的行为方式。

我特别感兴趣的是这个执行顺序:

1. 针对某个信号的signalfd，包括对这个信号的阻塞
2. 此信号的畅通
3. 此信号的 sigaction(默认处理程序或自定义处理程序)

这是未定义的行为还是必须发生的事情有标准/规范？处理程序是否总是优先于文件描述符？处理程序是否调用了 和 文件描述符触发了一个事件？设置 sigaction 是否会更改信号掩码，从而不需要渲染步骤 (2)？

我可以尝试从涉及实际代码的系统测试中推导出实际行为。然而，我当然更愿意找到一份详细的文档，并认为我自己无法找到正确的引用资料。

Answer 1

signalfd 的行为与 sigwaitinfo 相同，只是您可以通过文件描述符访问信息。这意味着 signalfd 接收信号同步，并且信号处理程序(或默认配置)被调用首先。

来源: TLPI 第 22.10 和 22.11 章(M. Kerrisk)。

行为定义明确，但未必符合预期，联机帮助页的措辞相当糟糕。说“通常...应该” 表明您实际上不必这样做，或者更糟的是作者不太确定。
如果你想让它“正常”工作，即你通常期望的方式(看，我也使用“正常”)，你必须阻止信号。否则，信号将通过文件描述符可用，但仍将首先调用处理程序(这是完全合法的，但大多数人可能会认为这是“奇怪的行为”)。

因此，存在两种不同的竞争条件。一个条件是您询问的条件，但尽管该行为有点出乎意料，但它定义明确且(有点)记录在案，如果您考虑一下，那么它并不是严格意义上的竞争条件。而是一种“双重交付”。
另一个竞争条件是在您创建 signalfd 之后但在您阻止信号之前信号到达的可能性。这是不太可能的，但原则上，这可能会发生。幸运的是，解决方案很简单，您可以先阻塞信号，然后创建文件描述符(如果中间有信号到达，文件描述符将立即准备就绪)。

您命名的命令序列(创建文件描述符、解锁，然后是 sigaction)具有类似的竞争条件。您应该先安装一个处理程序然后解除阻塞，否则可能会在处理程序到达之前传递信号。但这与 signalfd 无关。文件描述符在任何情况下仍可用于读取信号，但如果信号在解除阻塞和安装处理程序之间到达，则默认配置可能会终止进程。