无阻塞信号传输需要多长时间？

Question

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

Answer 1

关于分娩的信号，TLPI指出信号是“正常”时，任务下次计划，从内核模式切换到用户模式时，或交付“立即”当任务已经运行（大概是“立即“必须先发生中断才能发生，否则它会怎么做）。那么，无论这意味着什么，它不是严格的约束，但它与发生的事情非常接近。

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

实时信号排队排队，正常信号不是。这意味着正常信号的实现很可能仅仅是像一个任务字一样用作位掩码。生成一个“正常”信号意味着设置一个位，并且当操作系统接下来决定是否必须传递一个信号时，它将该字对零进行测试，并在必要时确定设置了哪个位，然后调用信号处理程序（如果有的话）。
为什么人们需要知道这一点唯一的实际原因是因为它有可能“丢失”信号。如果两个或更多的信号在第一个信号传输之前生成，它仍然只有一个信号。

实时信号的实现显然要复杂得多（需要排队等待实现的长度）。

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

Answer 2

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

如果您想了解Linux上的实现方式，请检查POSIX标准。上信号

大信息：

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

当产生信号时，它变得未决。正常情况下，它仍然在 待处理很短的时间，然后是交付到 进程信号。但是，如果这种信号是 当前被阻止，它可能会无限期地保持悬而未决 - 直到信号 是畅通。一旦畅通，它将立即交付 。

另一个摘录：

当信号被传递，无论是立即或长 延迟之后，对于该信号的指定的动作取。