Re: wait queue process state

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Wed, 2002-05-29 at 11:58, David Woodhouse wrote:
> Broken software can be fixed.

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.'

>From an abstract point of view there is no need for uninterruptible
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