Messages in this thread | | | Date | Sun, 29 Jun 2008 10:45:50 +0300 | From | Török Edwin <> | Subject | Re: Ctrl+C doesn't interrupt process waiting for I/O |
| |
Jeremy Fitzhardinge wrote: > Avi Kivity wrote: >> Applications should not assume that write() (or other syscalls) can't >> return EINTR. Not all filesystems have a bounded-time backing store. > > The distinction between 'fast' (filesystem) and 'slow' (terminals and > pipes) blocking syscalls goes back to the earliest days of Unix, and > is part of the ABI. Most filesystem syscalls are not documented to > ever return EINTR.
POSIX documents EINTR for write(), and the manpage on my Linux distro says the same. However I don't think introducing EINTR would be beneficial (it will likely cause applications that don't expect it to break).
> >> '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. > > Sure. It's the basic problem of trying to make network access > transparent by hiding the failure modes. You either need to put up > with spurious timeouts caused by transient failures, or unbounded > blocking on real failures. > > Regardless, NFS is the exception here, and making normal block-backed > filesystems start throwing EINTRs around would be a huge behavioural > change.
Agreed.
Best regards, --Edwin
| |