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

Question

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

Answer 1

If I remember correctly, the interrupt arrival bit is checked during the last T state of an 8085 instruction. 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.

Answer 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. 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.

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. May be this true only for real-time signals

Answer 3

The short answer is - yes, process get knowledge of a signal only on the next scheduled CPU timeslice.

How to know the process has received a signal - it may call sigprocmask(2).

Answer 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. 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.