进程如何知道它已收到信号 [英] How does a process come to know that it has received a signal
问题描述
如果我错了，请纠正我.以下是我对信号的理解:
<块引用>据我所知，信号生成和信号传递是两种不同的事物.为了产生信号，操作系统只是在位数组中设置了一点在过程控制中维护过程的块(PCB).每一位对应一个特定的信号，当一个位被设置时，这意味着该位对应的信号为待定.
交付:在转移控制权之前回到用户态的进程，内核总是检查挂起的这个过程的信号.这个检查必须发生在内核空间中，因为某些信号永远不能被忽略进程——即 SIGSTOP 和 SIGKILL.
那么这是否意味着信号只能在内核调度该进程即分配 CPU 时传递给该进程?进程在 CPU 上实际执行时是否可以获得信号?如果是这样，怎么可能，即进程如何知道一个信号正在等待它(因为它在用户模式下执行并且无法访问 PCB)
假设有多处理器机器，因此存在真正的并行性，即多个进程同时执行.进程 P1 在 cpu 1 上执行，进程 P2 在 cpu2 上执行，现在进程 P2(具有足够的权限)向进程 P1 发送信号.这个信号是现在就传递给 P1 还是在 P1 出于某种原因放弃 CPU 并在稍后的某个时间再次由内核重新调度后传递给 P1，然后将该信号传递给进程 P1.
请不要说这个问题取决于实现.如果您发现正确的答案是实现定义，那么我将在 Linux、FreeBSD 或您了解的任何 *nix 平台中寻找答案.
非常感谢您的帮助和耐心:)
问候
拉里
答案取决于实现:).在 Mac OS X(和 FreeBSD)上，信号是异步处理的——内核找到一个没有阻塞信号的线程，并在该线程上设置一个异步系统陷阱标志.下次内核调度该线程时，它会处理陷阱(退出进程、忽略陷阱或在用户空间调用信号处理程序)，而不是在用户空间安排线程的通常延续.
在 Solaris 上，实现有些相似，但它也提供基于硬件陷阱的同步信号 - 同步信号被传递到引发陷阱的线程，而异步信号以上述方式工作.
Linux 对 Solaris 做了类似的事情(我不确定该参考中的结论如何从讨论中得出，但讨论才是有用的).
Posix.4 也定义了实时信号，但我没有使用过.
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. 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.
So does this mean that signals can only be delivered to a process when the kernel is scheduling that process i.e allocating it CPU ? Can a process get a signal when it is actually executing on the CPU ? If so, how is it possible i.e 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)
Say there is multi processor machine and so there is real parallelism i.e 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. 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.
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.
Thanks a lot for your help and patience :)
Regards
lali
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. 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.
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).
Posix.4 also defines real-time signals, but I haven't worked with those.
这篇关于进程如何知道它已收到信号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
