What is the difference between TASK_KILLABLE and TASK_INTERRUPTIBLE?
It seems that TASK_KILLABLE should be a subset of TASK_INTERRUPTIBLE, since killing a task is one way to, um, interrupt it; however, according to sched.h here and here , it looks like TASK_KILLABLE, UN INTERRUPT.
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define TASK_WAKEKILL 128
#define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
For me it really is: when would I want to use wait_for_completion_interruptible_timeout versus wait_for_completion_killable_timeout ?
source to share
Turns out it was looking a little more for me: the article referenced by this somewhat related answer reads:
Kernel code that uses intermittent hibernation should always check to see if it woke up as a result of a signal, and if so, clear whatever it was doing and return -EINTR back to user space. The user space side must also understand that the system call has been interrupted and responds accordingly; not all user-space programmers are known for their zeal in this regard.
and
many of these application error issues don't really apply if the application is killed anyway. It doesn't matter if the developer thought about the possibility of interrupting the system call if the specified system call is doomed to never return to user space. So Matthew created a new sleeping state called TASK_KILLABLE; it behaves like TASK_UNINTERRUPTIBLE, except that fatal signals will interrupt sleep
source to share