传送无阻塞信号需要多长时间? [英] How long does it take for a non-blocked signal get delivered?
问题描述
- 当一个进程向另一个进程发送信号时，在什么情况下接收进程会一直等到重新安排运行时间?
- 在什么情况下会立即调用已安装的信号处理程序?
- 与直接调用相应的信号处理程序相比，发出信号时该过程会产生多少开销?
推荐答案
关于信号的传递，TLPI指出，在下一次计划任务，从内核模式切换到用户模式或立即"传递信号时，通常"传递信号当任务已经运行时(大概立即"必须通过首先触发一个中断来执行，否则它将如何执行).好吧，无论这意味着什么，它都没有严格的约束力，但是与发生的事情非常接近.
About delivery of signals, TLPI states that signals are "normally" delivered when a task is next scheduled, when switching from kernel mode to user mode, or "immediately" when the task is already running (presumably "immediately" would have to happen by firing an interrupt first, otherwise how could it do that). Well, whatever this means, it is not strictly binding, but it's very close to what happens.
您必须区分实时信号和正常"信号之间以及同步产生的正常"信号之间的区别，在大多数情况下，这些信号是由于硬件事件(例如，分段错误)而没有(不是)重新生成).
You have to distinguish between realtime and "normal" signals as well as between "normal" signals that are generated synchronously, most of the time because of a hardware event (e.g. segmentation fault) and those that aren't (they're genereated asnychronously).
实时信号被排队，正常信号不被.这意味着正常信号的实现极有可能只是一个像每个任务的单词一样用作位掩码的东西.
生成正常"信号意味着设置一个位，然后当OS接下来决定是否要发送信号时，它将测试该单词是否为零，并在必要时找出设置了哪些位，然后调用信号处理程序.(s)，如果有的话.
需要知道这一点的唯一实际原因是因为有可能丢失"信号.如果在发送第一个或更多信号之前已经生成了两个或更多信号，则总共仍然只有一个信号.
Realtime signals are queued, normal signals are not. That means that the implementation of normal signals is most likely merely something like one per-task word that serves as a bitmask.
Generating a "normal" signal means setting a bit, and when the OS next decides whether a signal has to be delivered, it tests the word against zero, and if necessary figures out which bit(s) were set, and calls the signal handler(s), if any, accordingly.
The only practical reason why one needs to know this is because it is possible to "lose" signals. If two or more signals are generated before the first is delivered, it's still only one signal alltogether.
实时信号的实现(需要排队直到达到与实现相关的长度)显然要复杂得多.
The implementation of realtime signals (which are required to queue up to a implementation-dependent length) is obviously much more complicated.
由于硬件事件(例如segfault)而发生的信号是同步生成的，就像生成称为 kill 的进程本身一样(第22.4章TLPI)，即立即交付""，这有两个原因.首先，做其他事情没有意义，其次，当陷阱处理程序返回时，已经发生了内核/用户切换.所以无论如何交付总是立即".
Signals that happen because of a hardware event (e.g. segfault) are generated synchronously, in the same way as if the process called kill on itself (chapter 22.4 TLPI), i.e. they are delivered "immediately", for two reasons. First, it does not make sense to do something else, and second there is already a kernel/user switch happening when the trap handler returns. So delivery is always "immediately" anyway.
这篇关于传送无阻塞信号需要多长时间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
