Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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