[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48671FF6.1070501@qumranet.com>
Date: Sun, 29 Jun 2008 08:39:02 +0300
From: Avi Kivity <avi@...ranet.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: Török Edwin <edwintorok@...il.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O
Jeremy Fitzhardinge wrote:
> Avi Kivity wrote:
>>>
>>> Yes, it's intended behaviour. Filesystem IO syscalls are considered
>>> "fast" and are interruptible. Usermode code can reasonably expect
>>> that file IO will never return EINTR.
>>
>> That's filesystem dependent; if you mount an nfs filesystem with the
>> 'intr' mount option, it will be interruptible (which makes sense, as
>> it is impossible to guarantee the server's responsiveness).
>
> 'intr' is a pretty bad idea, and I would never recommend it ('soft' is
> better). It's an excellent way to destroy data when a stray signal
> causes a syscall to fail with EINTR in an unexpected way (write being
> the obvious one, but link, unlink, truncate or even close can fail in
> odd ways can cause havok).
>
Applications should not assume that write() (or other syscalls) can't
return EINTR. Not all filesystems have a bounded-time backing store.
'soft' has its own problems; namely false positives when someone steps
on the network cable, temporarily blocking packet flow, or when using a
clustered server which may take some time to recover from a fault.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists