signalfd 和 sigaction 之间可以竞争吗？

Question

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

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

通常，通过文件描述符接收的一组信号 应该使用 sigprocmask(2) 来阻止信号，以防止信号被 根据他们的默认处置进行处理。

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

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

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

1. 针对某个信号的signalfd，包括对该信号的阻塞
2. 此信号解除阻塞
3. 此信号的sigaction（默认处理程序或自定义处理程序）

这是未定义的行为，还是有必须发生的标准/规范？处理程序是否总是优先于文件描述符？处理程序是否称为 并且 文件描述符会触发事件？设置sigaction是否会改变信号掩码，不需要渲染步骤（2）？

我可以尝试从涉及实际代码的系统测试中推导出实际行为。但是，我当然更喜欢查找详细的文档，并认为我自己无法找到正确的参考资料。

Answer 1

signalfd 的行为与sigwaitinfo 相同，但您可以通过文件描述符访问信息。这意味着signalfd 接收信号同步，然后调用信号处理程序（或任何默认配置）首先。

来源： TLPI 第 22.10 和 22.11 章（M. Kerrisk）。

行为是明确定义的，但不一定是人们所期望的，并且联机帮助页的措辞相当糟糕。说 “通常...应该” 表明您不是真的必须这样做，或者更糟的是作者不太确定。
如果您希望它“正常”工作，即按照您通常期望的方式（请参阅，我也使用“正常”），您必须阻止信号。否则，信号将通过文件描述符可用，但仍会首先调用处理程序（这是完全合法的，但大多数人可能会认为这是“奇怪的行为”）。

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

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