lkml.org 
[lkml]   [2002]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: wait queue process state
Date

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/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.093 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site