Let's assume that we have some really time consuming system call that is currently executing in kernel mode under the context of current user-space process, during the execution of such a system call the SIGKILL is sent to user process. What will happen in this case - would the process be killed immediately or it will wait till the end of system call ? if the process is killed immediately then does the same applies for the case when the user space process is killed while its executing interrupt handler(since interrupt handlers can be executed within the context of an arbitrary user-space process), because this sounds really weird - really important interrupt handler job my be aborted.

  • Don't confuse interrupt handlers, which react to an event triggered by hardware (clock, IO completion, ...), with signals, which are triggered by code. Commented Jul 16, 2021 at 5:53

4 Answers 4


Some system calls can be interrupted (see e.g. siginterrupt(3)). Otherwise the signal is only delivered when the call returns to userland.


An example for a really time-consuming system call is pause(). It never completes, except when the process receives a signal.

read() can be interruptable (a better term would be "signalable"), e.g. when reading from a serial line, or not, e.g. when reading from a block device.

Why? The original UNIX logic is as follows: We don't know if any input will be available at the serial line. Therefore, there must be a way to end the system call even if nothing is input. On the other hand, reading from a block device will always complete, possibly with an error when the disk is faulty.

UNIX has evolved a lot. Nowadays, non-interruptable read()s are possible that never complete. Example: Reading from an NFS-mounted filesystem when the NFS server is down and the mount is hard.


True interrupt handlers are in the kernel, and not really associated with a user process. Signal handlers are the closest thing a user process has to an interrupt handler. Some signals are blocked during signal handlers, but SIGKILL is not one of them, so it would exit immediately, just like it would for any other user code.


A signal can only be delivered when a return to user mode (i.e. exit from kernel mode) is executed and it is your process scheduled to run (usually a privileged assembly instruction that restores the process context and may or may not set user mode, depending whether your process was within a system call or not) - this can be when a system call returns, or when an interrupt handler returns.

To answer your specific questions, it will wait until the end of the system call (which may or may not be interruptible), and if an interrupt handler returns (after completing all of it's work) to your process (i.e. it returns to kernel mode not user mode), the signal won't be delivered until your process subsequently returns from the system call (i.e. to user mode).

If the system call was interrupted (returns EINTR) and is "restartable", the user code supporting the system call interface may choose to automatically reenter the system call without returning to your user code, after your signal handler has run.

Also check this out ...

Finally, the implication here is that a signal may never be delivered to a process, including SIGKILL, if the process never returns from a system call (resulting in an "unkillable" process).

You must log in to answer this question.

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