When one process sends a signal to another process, does receiving process wait until it is rescheduled to run? So if every 1 ms we choose one process to run, does that mean the latency from generating the signal to delivery of the signal is around 0.5 ms? (Suppose we only have two processes.)
And more generally, how are signals implemented in Linux?


This is (somewhat) undefined.

If the receiving process is set up to take action upon receipt of the signal (that is, the signal is not ignored or blocked, then the process becomes runnable. If it has sufficient priority, then it is also scheduled immediately, but that is not guaranteed.


Don't guess the value.

Sending a signal to a process is just like (unreliably) queued an event to this process. When the process was rescheduled to run, the scheduler check the process's queue, and arrange the action to be taken. The problem is you never know when the scheduler turn it's eye on this process.

So, programmers who uses signals must realize that there would be an unpredictable and unavoidable latency between signal arriving and the action be taken. So, don't try to guess it's value.

Even real-time signal does no help on this latency. Raising the process's schedule priority is much more effective. But your code should never rely on any scheduler's feature to run correctly.

See Chapter 10 of APUE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.