When executing in the kernel, threads can block waiting for something, such as a lock, or a socket becoming readable, or a device responding (IRQ). Such a wait should always support being interrupted, or cancelled. This usually happens when the thread receives a signal. In some cases, such a signal is not fatal to the thread, and the thread could continue working after handling the signal.

Other times — with special signals such as SIGKILL — we should not deliver the signal to userspace, but just kill the thread altogether. However, we still have to make sure the thread cleans up after itself inside the kernel. To make that possible, killing the thread does not immediately kill it (as far as the userspace is concerned, it is immediate, as the thread will not execute any more userspace code, but this is not true for the kernel). Instead, the thread gets told that it should die (see set_should_die()) and woken up. Whatever the thread may have been waiting or blocking on (including locks!) should always support successful returns and "killed by a signal" returns, and swiftly exit, while cleaning up resources, in the latter case. Once the thread returns to a certain boundary (currently, once it returns from Syscall::handle(), so just before returning to userspace), it actually dies.

This mechanism already exists on the kernel in the form of Thread::BlockResult, and most blocking code already handles this correctly, i.e. by failing fast in case block() returns something other than WokeNormally. But there still are places where threads get blocked and do not get unblocked when/if they get killed. Notably, Thread::wait_on() doesn't have any means for the killed process to be woken up (nor to know that it woke up abnormally), and waiting for IRQs used to actually use an endless loop, disregarding killability.

So to reiterate:

• Any mechanism/API that may block has to support the unhappy path of the thread getting killed
• In this case it should let the caller know it has returned unsuccessfully
• Upon seeing this, the caller has to exit as soon as possible (not continue blocking), while cleaning up
• There should be no way to get a thread into a state where it cannot be killed (or into a state where it can be killed, but that doesn't result in it dying instantly, i.e. within milliseconds)
• The above should hold even in presence of bugs like deadlocks and/or buggy hardware
• It's only when control reaches the syscall/userspace boundary that the thread actually dies