An overview on how signals work, in order to complete the other answers which are very good:

The execution of a process can happen in two modes: in userspace or in kernelspace. When in userspace, the process executes the code of its program whereas in kernelspace, it executes the code of the kernel. Processes run in userspace as much as possible to do their work but enter kernelspace from time to time during their execution when they make a system call (which is necessary for any privileged operation on the hardware or shared resources of the system itself, like reading a file) or when they are interrupted in their execution.

They are two cases in which a signal is handled: when a process returns into userspace after having finished a system call, or when it wakes up from an interruptible sleep and resumes its execution. In both cases, the process is in kernelspace. Before anything else, the kernel checks if some signal is pending for the process and acts upon it. If a handler is defined for the signal for example, it makes the process execute it upon its return into userspace. As you've said yourself, the case of KILL is special because it cannot be captured. So, it's actually a simple case for the kernel: the return to userspace is cancelled and the process is killed right away, which means that it won't execute any code in userspace anymore, its memory is freed, its parent process is notified of its death, etc.

An overview of how signals work, in order to complete the other answers which are very good:

The execution of a process can happen in two modes: in userspace or in kernelspace. When in userspace, the process executes the code of its program whereas in kernelspace, it executes the code of the kernel. Processes run in userspace as much as possible to do their work but enter kernelspace from time to time during their execution when they make a system call (which is necessary for any privileged operation on the hardware or shared resources of the system itself, like reading a file) or when they are interrupted in their execution.

They are two cases in which a signal is handled: when a process returns into userspace after having finished a system call, or when it wakes up from an interruptible sleep and resumes its execution. In both cases, the process is in kernelspace. Before anything else, the kernel checks if some signal is pending for the process and acts upon it. If a handler is defined for the signal for example, it makes the process execute it upon its return into userspace. As you've said yourself, the case of KILL is special because it cannot be captured. So, it's actually a simple case for the kernel: the return to userspace is cancelled and the process is killed right away, which means that it won't execute any code in userspace anymore, its memory is freed, its parent process is notified of its death, etc.

An overview on how signals work, in order to complete the other answers which are very good:

The execution of a process can happen in two modes: in userspace or in kernelspace. When in userspace, the process executes the code of its program whereas in kernelspace, it executes the code of the kernel. Processes run in userspace as much as possible to do their work but enter kernelspace from time to time during their execution when they make a system call (which is necessary for any privileged operation on the hardware or shared resources of the system itself, like reading a file) or when they are interrupted in their execution.

They are two cases in which a signal is handled: when a process returns into userspace after having finished a system call, or when it wakes up from an interruptible sleep and resumes its execution. In both cases, the process is in kernelspace. Before anything else, the kernel checks if some signal is pending for the process and acts upon it. If a handler is defined for the signal for example, it makes the process execute it upon its return into userspace. As you've said yourself, the case of KILL is special because it cannot be captured. So, it's actually a simple case for the kernel: the return to userspace is cancelled and the process is killed right away, its resources freed, etc.

An overview on how signals work, in order to complete the other answers which are very good:

The execution of a process can happen in two modes: in userspace or in kernelspace. When in userspace, the process executes the code of its program whereas in kernelspace, it executes the code of the kernel. Processes run in userspace as much as possible to do their work but enter kernelspace from time to time during their execution when they make a system call (which is necessary for any privileged operation on the hardware or shared resources of the system itself, like reading a file) or when they are interrupted in their execution.

They are two cases in which a signal is handled: when a process returns into userspace after having finished a system call, or when it wakes up from an interruptible sleep and resumes its execution. In both cases, the process is in kernelspace. Before anything else, the kernel checks if some signal is pending for the process and acts upon it. If a handler is defined for the signal for example, it makes the process execute it upon its return into userspace. As you've said yourself, the case of KILL is special because it cannot be captured. So, it's actually a simple case for the kernel: the return to userspace is cancelled and the process is killed right away, which means that it won't execute any code in userspace anymore, its memory is freed, its parent process is notified of its death, etc.