Given an infinite number of monkeys yes. The 'disk I/O is not
interruptible' assumption is buried in vast amounts of software. This
isnt a case of sorting out a few misbehaving applications, you can start
with some of the most basic unix programs like 'ed' and work outwards.
> There are few excuses for uninterruptible sleep.
> Most of them are 'I was too lazy to write the cleanup path.'
sleep since an uninterruptible sleep can be considered an interruptible
sleep which clones a recovery thread and returns -EINTR, plus a little
locking if needed.
> What I'd _really_ like at the moment is an option to allow read_inode() to
> be interruptible. Currently there's no way for it to exit without leaving a
> bad inode behind, which prevents the _next_ iget() for that inode from
> actually succeeding.
If I remember rightly stat() is not interruptible anyway. I don't
actually argue with the general claim. If I was redesigning unix right
now I would have no blocking calls, just 'start_xyz' and wait/notify.
However the unix api as defined has certain limitations and assumptions
we can pretty much never change. Open with O_INTR maybe would work ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/