I am reading some Linux documentation about 'signals' and I still have these questions making noise in my mind:

1) A 'signal' handler execution is done when the 'target' process receives its execution token from the Scheduler?

2) Or 'signal' handler execution takes place in whatever process 'context' happens to be executing when the 'signal' was sent? (The same style as a hardware ISR).

3) What about process execution priorities? Are they swept away when dealing with 'signals'?


1 Answer 1


1) The signal handler is executed the next time the target process returns from kernel mode to user mode.

This occurs either when the process is scheduled to run again after a hardware interrupt (and it wasn't already running in kernel mode), or when the process returns from a system call (on some architectures, these are the same thing).

In normal operation, when leaving kernel mode, your process will simply return to the next instruction after the point where it originally left user mode.

However if a signal is pending for your process, the kernel will re-write your processes context such that the return to user mode will instead go to the first instruction of your signal handler and your stack will have been modified to look like you had made a "special" subroutine call to the signal handler at the point where you originally left user mode (the return from this "special" subroutine call involves making a system call to restore the original state).

For details read this, this and this.

So the 'target' process may receive its execution token from the Scheduler any number of times before the signal handler is finally executed (if it happens to stay in kernel mode for some reason).

2) No - the signal handler will only ever execute in the user mode context of your process.

3) The aren't really any execution priorities in a time-shared system such as Linux, unless you count the nice value of a process, so you can't sweep away something that isn't there.

Things are complicated by threads and so-called real time scheduling policies, so the comments above are only valid for single-threaded processes running with non-real-time scheduling policies (the only sort of process that existed in the good old days :-).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .