TASK_KILLABLE

Posted Jul 24, 2008 17:49 UTC (Thu) by mcortese (guest, #52099)
In reply to: TASK_KILLABLE by nix
Parent article: TASK_KILLABLE

If it's holding a lock (which it generally is, or the sleep would be interruptible) it's probably doing that because some data structure protected by that lock is in an inconsistent state.

...whereas a KILLABLE task, despite having data in inconsistent state and not knowing how to deal with most incoming signals (and in that being much like the UNINTERRUPTIBLE variety), despite all that, it still knows how to deal with just one type of signal, kill.

Are there a lot of such tasks out there? (irony not intended, I really want to understand how much this change can improve the kernel)

TASK_KILLABLE

Posted Jul 25, 2008 20:28 UTC (Fri) by nix (subscriber, #2304) [Link]

If it's in KILLABLE state, it *does* know how to deal with signals within 
the kernel, and its in-kernel state can be cleanly unwound. The reason 
that this doesn't propagate up to userspace as an EINTR is simply that 
there is in effect a Unix guarantee that filesystem operations cannot be 
interrupted, and the vast majority of userspace code relies on this 
guarantee and will malfunction if it starts getting EINTRs from tasks. 
(This is what the old 'intr' option did, and boy were the results messy.)

That's why it only responds to SIGKILL: because SIGKILL, by definition, 
doesn't get propagated to userspace, because the process's userspace 
component is killed by the SIGKILL.