Re: wait queue process state

[David Woodhouse <dwmw2@infradead.org>]

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