How long does it take for a non-blocked signal get

Question

1. When one process sends a signal to another process, under what circumstances does receiving process wait until it is rescheduled to run?
2. Under what circumstances does the installed signal handler get invoked immediately?
3. How much overhead does the process incur when raising a signal compared to just call the corresponding signal handler directly?

Answer 1

Basically, signals are asynchronous. They rely on signal handlers to execute code when a signal is received because you never know when that will be due to factors such as the process scheduler. The latency of sending a signal is based on the hardware/software interrupt, which is based on the clock speed.

If you want to find out how something is implemented on Linux, check the POSIX standards.

Great information on Signals:

http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-Handling

When a signal is generated, it becomes pending. Normally it remains pending for just a short period of time and then is delivered to the process that was signaled. However, if that kind of signal is currently blocked, it may remain pending indefinitely--until signals of that kind are unblocked. Once unblocked, it will be delivered immediately.

Another excerpt:

When the signal is delivered, whether right away or after a long delay, the specified action for that signal is taken.

Answer 2

About delivery of signals, TLPI states that signals are "normally" delivered when a task is next scheduled, when switching from kernel mode to user mode, or "immediately" when the task is already running (presumably "immediately" would have to happen by firing an interrupt first, otherwise how could it do that). Well, whatever this means, it is not strictly binding, but it's very close to what happens.

You have to distinguish between realtime and "normal" signals as well as between "normal" signals that are generated synchronously, most of the time because of a hardware event (e.g. segmentation fault) and those that aren't (they're genereated asnychronously).

Realtime signals are queued, normal signals are not. That means that the implementation of normal signals is most likely merely something like one per-task word that serves as a bitmask.
Generating a "normal" signal means setting a bit, and when the OS next decides whether a signal has to be delivered, it tests the word against zero, and if necessary figures out which bit(s) were set, and calls the signal handler(s), if any, accordingly.
The only practical reason why one needs to know this is because it is possible to "lose" signals. If two or more signals are generated before the first is delivered, it's still only one signal alltogether.

The implementation of realtime signals (which are required to queue up to a implementation-dependent length) is obviously much more complicated.

Signals that happen because of a hardware event (e.g. segfault) are generated synchronously, in the same way as if the process called kill on itself (chapter 22.4 TLPI), i.e. they are delivered "immediately", for two reasons. First, it does not make sense to do something else, and second there is already a kernel/user switch happening when the trap handler returns. So delivery is always "immediately" anyway.