3 ms·

Why does TASK_UNINTERRUPTIBLE exist? 'I'm sorry Dave'?

• ovi256 8y ago
  Obviously for the app developpers that write rocket flight computers. They also don't use free, their garbage collection is implemented in a physical mechanism.
• caf 8y ago
  It's because for a long time, there was only "interruptible" and "uninterruptible", where "interruptible" meant that any signal could interrupt it. Historically, many operations were specified not to be interrupted by signals - reads and writes on disk files (as opposed to "slow devices" like ttys and sockets), mkdir(2), fsync(2), etc. They're not allowed to return EINTR. This meant using an uninterruptible sleep, which has the consequence that SIGKILL can't interrupt it either. That's why the code in top or ps for uninterruptible sleep is 'D' - historically it meant "Disk Wait". TASK_KILLABLE is a more recent invention, which can be interrupted only by fatal signals. The code doing the wait still has to unwind as if it were going to exit from the syscall with an error, but userspace won't see that error because it will die from the signal instead.
• notriddle 8y ago
  Because the call doesn't support rolling back partial progress. Imagine if you interrupted `mount`, and it had written to the directory table but hadn't yet initialized the underlying filesystem and now the kernel reads uninitialized memory whenever you look at that directory (or, less disastrously, the mutex that protects that table is left locked and you can never mount or unmount anything ever again).