我想知道当两种机制发生碰撞时会发生什么/应该发生什么.有竞争条件吗？在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.
因此,它说“通常”我们使用信号掩码以防止(默认)处理程序处理信号.它并没有说我们必须在连接文件描述符时阻止该信号.不幸的是,手册页没有说明当我们不阻止信号时会发生什么.
这看起来像定义不明确的行为.我不相信这实际上没有明确定义,我想知道这里是否有人知道我是否可以找到关于系统应该如何表现的详细规范或ii)它的行为方式.
我特别感兴趣的是这个执行顺序：
> signalfd表示某个信号,包括此信号的阻塞
>解除此信号的阻塞
>此信号的sigaction(默认处理程序或自定义处理程序)
这是未定义的行为还是存在必须发生的标准/规范？处理程序是否始终优先于文件描述符？是否调用了处理程序并且文件描述符触发了事件？设置sigaction是否会更改信号掩码,渲染步骤(2)是否必要？
我可以尝试从涉及实际代码的系统测试中推导出实际行为.但是,我当然更愿意找到一份详细的文档,并认为我自己找不到合适的参考资料.
解决方法
资料来源：TLPI第22.10和22.11章(M. Kerrisk).
行为是明确定义的,但不一定是人们所期望的,并且手册的措辞相当糟糕.说“通常……应该”表明要么你不是真的必须,要么更糟糕的是作者不太确定.
如果你想让它“正常”工作,即你通常期望的方式(参见,我通常也使用“),你必须阻止信号.否则,信号将通过文件描述符提供,但仍将首先调用处理程序(这完全是合法的,但大多数人可能会认为这是“奇怪的行为”).
因此,存在两种不同的竞争条件.一个条件是你问的问题,但是虽然行为有点出乎意料,但它是明确的,并且(有点)记录,如果你考虑它,那么它不是严格的竞争条件.相反,它是一种“双重交付”.
另一种竞争条件是在您创建信号fd之后但在阻止信号之前信号到达的可能性.这是不太可能的,但原则上,这可能发生.幸运的是,解决方案很简单,您可以先阻止信号然后创建文件描述符(如果信号到达之间,它将立即就绪).
您命名的命令序列(创建文件描述符,取消阻止,然后是sigaction)具有类似的竞争条件.您应首先安装一个处理程序,然后取消阻止,或者可以在处理程序存在之前传递信号.但这与signalfd无关.在任何情况下,文件描述符仍然可以用于读取信号,但是如果信号在解锁和安装处理程序之间到达,则默认处置可能会终止进程.
