TASK_KILLABLE 似乎应该是 TASK_INTERRUPTIBLE 的一个子集,因为终止任务是,嗯,中断它的一种方式;然而,根据 sched.h here和 here看起来 TASK_KILLABLE 是 UNINTERRUPTIBLE。
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define TASK_WAKEKILL 128
#define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
这对我来说真正归结为;我什么时候想使用 wait_for_completion_interruptible_timeout与 wait_for_completion_killable_timeout ?
最佳答案
事实证明,更多的搜索为我找到了答案:article在 this somewhat related answer 中引用状态:
Kernel code which uses interruptible sleeps must always check to see whether it woke up as a result of a signal, and, if so, clean up whatever it was doing and return -EINTR back to user space. The user-space side, too, must realize that a system call was interrupted and respond accordingly; not all user-space programmers are known for their diligence in this regard.
和
many of these concerns about application bugs do not really apply if the application is about to be killed anyway. It does not matter if the developer thought about the possibility of an interrupted system call if said 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 with the exception that fatal signals will interrupt the sleep
关于linux - TASK_KILLABLE 和 TASK_INTERRUPTIBLE 有什么区别?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27002488/