Messages in this thread | | | From | David Woodhouse <> | Subject | Re: wait queue process state | Date | 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/
| |