lkml.org 
[lkml]   [2008]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2008-06-29 07:41    [W:0.458 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site