Linked by David Adams on Thu 2nd Oct 2008 17:40 UTC
The Linux Kernel version 2.6.25 introduces a new Linux process sleeping state, TASK_KILLABLE: If a process is sleeping killably in this new state, it works like TASK_UNINTERRUPTIBLE with the bonus that it can respond to fatal signals. This feature is generally an improvement over the existing options -- after all, it is another way to keep from getting stuck with dead processes.
Thread beginning with comment 332267
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-01-16
I want to give a little clarification about what's going on here.
What's going on here does not affect user-space at all.
The scenario is as follows: The program in user-space asks for some operation in kernel-space, mostly this would be some I/O. Then something gets stuck in kernel-space, e.g. caused by nasty behaviour of a device driver. The program stays in an _inconsistent_ state forever, and nobody is allowed to clean it up.
User-space never gains any knowledge about this. Even in the new KILLABLE state, user-space would never receive the KILL signal, the program would just be terminated instead of finishing the operation which made it stuck.
The question now is: Why couldn't KILLABLE just replace UNINTERRUPTABLE? The idea behind this is, that some operations, if not properly finished or aborted, leave the _kernel_ in an inconsistent state. That means for example, a lock could have been set and would need to be removed.
For KILLABLE to work, specific parts of the kernel, which set the process into the UNINTERRUPTABLE state before, need to be rewritten to use this new state and make sure it works properly.
What I don't understand, though:
- with current UNINTERRUPTABLE, the inconsistent state problem is still there, and will never be resolved, anyway. So how does it help not to at least clean as much as possible?
- what happened with INTERRUPTABLE sleeping processes? The inconsistent state would also not be resolved just by the process catching signals and dealing with them in user-space, would it?
Edited 2008-10-02 21:03 UTC