Re: Ctrl+C doesn't interrupt process waiting for I/O

["J. Bruce Fields" <bfields@fieldses.org>]

On Sat, Jun 28, 2008 at 10:13:54PM -0700, 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).

Yipes.

> 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).

And with "soft" all that can happen with the need for the stray
signal....

I suppose the relative likelihoods of hitting the problem under "soft"
and "intr" may vary depending on the details of your setup.  But in
general I'd've thought it'd be easier to control stray signals than,
say, stray network problems.

--b.

> I don't know of any other filesystem with a similarly bad option.