linux - 未阻塞的信号需要多长时间才能传递？

Question

1. 当一个进程向另一个进程发送信号时，接收进程在什么情况下会等到它重新调度运行？
2. 在什么情况下会立即调用已安装的信号处理程序？
3. 与直接调用相应的信号处理程序相比，在发出信号时该过程会产生多少开销？

Answer 1

关于信号的传递，TLPI 指出，在下一次调度任务时、从内核模式切换到用户模式时、或者在任务已经运行时“立即”传递信号（大概“立即”必须通过首先触发中断，否则它怎么能这样做）。好吧，不管这意味着什么，它不是严格绑定的，但它非常接近发生的事情。

您必须区分实时信号和“正常”信号以及同步生成的“正常”信号，大部分时间是由于硬件事件（例如分段错误）和那些不是（它们是异步生成的） ）。

实时信号排队，正常信号没有。这意味着正常信号的实现很可能只是类似于每个任务的一个用作位掩码的字。
生成“正常”信号意味着设置一个位，当操作系统接下来决定是否必须传递信号时，它会针对零测试该字，并在必要时确定设置了哪些位，并调用信号处理程序(s)，如果有的话，相应地。
需要知道这一点的唯一实际原因是有可能“丢失”信号。如果在传递第一个信号之前生成了两个或多个信号，那么它仍然只是一个信号。

实时信号的实现（需要排队到与实现相关的长度）显然要复杂得多。

由于硬件事件（例如段错误）而发生的信号是同步生成的，就像进程调用kill自身一样（第 22.4 章 TLPI），即它们“立即”传递，有两个原因。首先，做其他事情没有意义，其次，当陷阱处理程序返回时，已经发生了内核/用户切换。所以无论如何交付总是“立即”的。

Answer 2

基本上，信号是异步的。它们依靠信号处理程序在收到信号时执行代码，因为您永远不知道什么时候会由于进程调度程序等因素而发生。发送信号的延迟取决于硬件/软件中断，而硬件/软件中断是基于时钟速度的。

如果您想了解某些东西是如何在 Linux 上实现的，请查看POSIX标准。

关于信号的重要信息：

http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-Handling

当一个信号产生时，它就变成了pending。通常它会在很短的时间内保持未决状态，然后被传递到发出信号的进程。但是，如果这种信号当前被阻塞，它可能会无限期地保持等待状态——直到那种信号被解除阻塞。解封后，即刻送达。

另一个摘录：

当信号被传递时，无论是立即还是经过长时间的延迟，都会对该信号采取指定的操作。