Re: wait queue process state

David Woodhouse (dwmw2@infradead.org)
Wed, 29 May 2002 12:56:03 +0100


alan@lxorguk.ukuu.org.uk said:
> 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.

Still probably worth doing in the long term. In the short term, we could
possibly have a sysctl or personality flag to disable it for the benefit of
broken software. I'm in favour of just letting it break though, to be
honest - it's _already_ possible to trigger the breakage in some
circumstances and making it more reproducible is a _good_ thing.

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

stat() would be restartable. With -ERESTARTNOINTR would prevent us from
ever actually returning -EINTR if the signal handler exists and returns.

I suspect open() would actually be more of a pain -- but that we could
probably also restart if we get interrupted as early as the read_inode()
stage.

You don't actually have to redesign the API, although I agree it could do
with it. We could get rid of the bloody silly returning status _and_ length
in one return code from read()/write() etc.

--
dwmw2

- 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/