为特定信号指定处理程序的经典方法是通过sigaction。 Linux还提供signalfd功能，我们可以将信号连接到文件描述符，然后将select /（e）poll应用于该描述符，这完全符合许多事件循环驱动系统的概念。
我想知道当两种机制发生碰撞时会发生什么/应该发生什么。有竞争条件吗？在signalfd联机帮助页（http://man7.org/linux/man-pages/man2/signalfd.2.html）上，我们读到：
通常，通过文件描述符接收的信号集 应该使用sigprocmask（2）阻止，以防止信号 根据他们的默认处置来处理。
所以，它说＃34;通常＆＃34;我们使用信号掩码来防止（默认）处理程序处理信号。当我们有一个连接到它的文件描述符时，它并没有说我们必须阻止该信号。不幸的是，手册页没有说明当我们不阻止信号时会发生什么。
这看起来像定义不明确的行为。我不相信这实际上没有明确定义，我想知道这里是否有人知道我）我是否可以找到关于系统应该如何表现的详细规范或 ii ）它的表现如何。
我特别感兴趣的是这个执行顺序：
这是未定义的行为还是存在必须发生的标准/规范？处理程序是否始终优先于文件描述符？名为的处理程序和文件描述符是否会触发事件？设置sigaction是否会更改信号掩码，不需要渲染步骤（2）？
我可以尝试从涉及实际代码的系统测试中推导出实际行为。但是，我当然更愿意找到一份详细的文档，并认为我自己找不到合适的参考资料。
答案 0 :(得分：11)
signalfd的行为与sigwaitinfo完全相同。这意味着signalfd同步接收信号 ，信号处理程序（或默认处置中的任何一个）称为 first 。
来源： TLPI第22.10和22.11章（M. Kerrisk）。
行为是明确定义的，但不一定是人们所期望的，并且手册的措辞相当糟糕。说“通常......应该”表明你不是真的必须，或者更糟糕的是作者不太确定。
如果你希望它“正常”工作，即你通常期望的方式（参见，我通常也使用“），你必须阻止信号。否则，信号将通过文件描述符提供，但仍将首先调用处理程序（这完全合法，但大多数人可能会认为这是“奇怪的行为”）。
因此，存在两种不同的竞争条件。一个条件是你问的问题，但是虽然行为有点出乎意料，但它是明确定义的并且（有点）记录，如果你考虑它，那么它不是严格意义上的竞争条件。相反，它是一种“双重交付”
另一种竞争条件是在您创建signalfd之后但在阻止信号之前信号到达的可能性。这是不太可能的，但原则上，这可能发生。幸运的是，解决方案很简单，您可以先阻止信号，然后创建文件描述符（如果信号到达，它将立即就绪）。
您命名的命令序列（创建文件描述符，取消阻止，然后sigaction）具有类似的竞争条件。您应首先安装一个处理程序然后取消阻止，或者可以在处理程序存在之前传递信号。但这与signalfd无关。在任何情况下，文件描述符仍可用于读取信号，但如果信号在解锁和安装处理程序之间到达，则默认处置可能会终止进程。