简体繁体 English

一个过程如何知道它已收到信号

[英]How does a process come to know that it has received a signal

原文 2009-12-07 14:05:17 4 4 linux/ unix/ signals

Please correct me if i am wrong. 如果我错了，请纠正我。 Here is my understanding about signals: 以下是我对信号的理解：

As far as i know, signal generation and signal delivery are 2 different things. 据我所知，信号生成和信号传递是两回事。 In order to generate a signal, the OS simply sets a bit in a bitarray maintained in the Process Control Block(PCB) of the process. 为了产生信号，OS简单地在过程的过程控制块（PCB）中维持的位阵列中设置一位。 Each bit corresponds to a particular signal, and when a bit is set, it means the signal corresponding to the bit is pending. 每个位对应一个特定信号，当一个位置位时，表示该位对应的信号未决。

Delivery: Before transferring control back to a process in user mode, the Kernel always checks the pending signals for this process. 交付：在将控制权转移回用户模式的流程之前，内核始终会检查此流程的待处理信号。 This check must happen in Kernel space because some signals can never be ignored by a process – namely SIGSTOP and SIGKILL. 此检查必须在内核空间中进行，因为进程永远不会忽略某些信号 - 即SIGSTOP和SIGKILL。

So does this mean that signals can only be delivered to a process when the kernel is scheduling that process ie allocating it CPU ? 那么这是否意味着只有在内核调度该进程（即分配CPU）时才能将信号传递给进程？ Can a process get a signal when it is actually executing on the CPU ? 当一个进程在CPU上实际执行时，它是否可以获得信号？ If so, how is it possible ie how the process comes to know that a signal is pending for it (since it is executing in User mode and cannot access the PCB) 如果是这样，那怎么可能，即该过程如何知道信号正在等待它（因为它在用户模式下执行而无法访问PCB）

Say there is multi processor machine and so there is real parallelism ie multiple processes are executing at the same time. 假设有多处理器机器，因此存在真正的并行性，即多个进程同时执行。 Process P1 is executing on cpu 1 and process P2 is executing on cpu2 and now process P2(having sufficient privileges) sends a signal to process P1. 进程P1在cpu 1上执行，进程P2在cpu2上执行，现在进程P2（具有足够的权限）向进程P1发送信号。 Will this signal be delivered to P1 right now or will it be delivered after P1 relinquishes the CPU for some reason and is again rescheduled at some later time by the Kernel and then this signal is delivered to process P1. 此信号是立即传送到P1还是在P1因某种原因放弃CPU之后传送，并在稍后由内核重新安排，然后将此信号传送到过程P1。

Please don't say this question is implementation dependent. 请不要说这个问题是依赖于实现的。 If you find that the right answer is implementation defined then i am looking for answers in Linux, FreeBSD or any *nix platform for which you have knowledge of. 如果您发现正确的答案是实现定义，那么我正在寻找Linux，FreeBSD或您知道的任何* nix平台的答案。

Thanks a lot for your help and patience :) 非常感谢您的帮助和耐心:)

Regards 问候

lali 拉利

4 个解决方案

The answer is implementation dependent :). 答案是依赖于实现:)。 On Mac OS X (and FreeBSD), signals are handled asynchronously - the kernel finds a thread which is not blocking the signal, and sets an Asynchronous System Trap flag on that thread. 在Mac OS X（和FreeBSD）上，信号是异步处理的 - 内核找到一个没有阻塞信号的线程，并在该线程上设置Asynchronous System Trap标志。 The next time the kernel schedules that thread, it handles the trap (quitting the process, ignoring the trap, or invoking the signal-handler in user space as appropriate) rather than arranging the usual continuation of the thread in user-space. 下次内核调度该线程时，它会处理陷阱（退出进程，忽略陷阱，或在用户空间中调用信号处理程序），而不是在用户空间中安排线程的常规延续。

On Solaris, the implementation is somewhat similar, although it also offers synchronous signals based on hardware traps - synchronous signals are delivered to the thread that raised the trap, while asynchronous signals work in the way described above. 在Solaris上，实现有点类似，尽管它还提供基于硬件陷阱的同步信号 - 同步信号被传递到引发陷阱的线程，而异步信号以上述方式工作。

Linux does something similar to Solaris (I'm not sure how the conclusion in that reference follows from the discussion, but it's the discussion that is useful). Linux做了类似于 Solaris的事情（我不确定该引用中的结论是如何从讨论中得出的，但这是有用的讨论）。

Posix.4 also defines real-time signals, but I haven't worked with those. Posix.4还定义了实时信号，但我没有使用过它们。

The short answer is - yes, process get knowledge of a signal only on the next scheduled CPU timeslice. 简短的回答是 - 是的，进程仅在下一个计划的CPU时间片上获得信号的知识。

How to know the process has received a signal - it may call sigprocmask(2). 如何知道进程已收到信号 - 它可能会调用sigprocmask（2）。

Process P1 is executing on cpu 1 and process P2 is executing on cpu2 and now process P2(having sufficient privileges) sends a signal to process P1. 进程P1在cpu 1上执行，进程P2在cpu2上执行，现在进程P2（具有足够的权限）向进程P1发送信号。 Will this signal be delivered to P1 right now or will it be delivered after P1 relinquishes the CPU for some reason and is again rescheduled at some later time by the Kernel and then this signal is delivered to process P1. 此信号是立即传送到P1还是在P1因某种原因放弃CPU之后传送，并在稍后由内核重新安排，然后将此信号传送到过程P1。

As far as i know on last linux kernels execution of P1 may be paused when P2 emit signal and signal will be delivered immediately. 据我所知，在最后的Linux内核上，当P2发出信号并且信号将立即传送时，P1的执行可能暂停。 May be this true only for real-time signals 对于实时信号，这可能是真的

If I remember correctly, the interrupt arrival bit is checked during the last T state of an 8085 instruction. 如果我没记错的话，在8085指令的最后一个T状态期间检查中断到达位。 So there has to be a way to either generate a real interrupt on signal arrival, or there has to be a (constant?)code slice before the signal bit is checked. 因此必须有一种方法可以在信号到达时产生实际中断，或者在检查信号位之前必须有一个（常数？）代码片。

Unfortunately, it appears that the only way to answer some kernel behaviour related questions is to go through the source code, because they are so "implementation dependent". 不幸的是，似乎回答一些与内核行为相关的问题的唯一方法是通过源代码，因为它们是“依赖于实现的”。 Programming the computer really is nothing short of harassment - what a profession to choose! 对电脑进行编程实际上就是骚扰 - 这是一个什么样的职业选择！

Just try to be perfect, and hope this website helps. 试着做到完美，希望这个网站有所帮助。