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

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.