Hi,

This came up in a discussion recently; signal(7) says:

       If a blocked call to one of the following interfaces is interrupted
       by a signal handler, then the call will be automatically restarted
       after the signal handler returns if the SA_RESTART flag was used;
       otherwise the call will fail with the error EINTR:

           * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
             "slow" devices.  A "slow" device is one where the I/O call may
             block for an indefinite time, for example, a terminal, pipe, or
             socket.  (A disk is not a slow device according to this
             definition.)  If an I/O call on a slow device has already
             transferred some data by the time it is interrupted by a signal
             handler, then the call will return a success status (normally,
             the number of bytes transferred).

In other words, for "slow" devices, it's defined that you get restart or EINTR depending on SA_RESTART setting; that's fine. However, while it seems the _intention_ of the last paragraph is to say that "fast" devices never can get EINTR (always restart), it is possible to read it leaving the behavior of fast devices entirely up to the reader's imagination (ie., the paragraph simply says nothing about that). The practical behavior, to the best of my knowledge, is that these calls against filesystems on disks always restart (never EINTR). I believe this should be written out more explicitly in this section.

A different question is what counts as “fast” or “slow” in edge cases. In particular, NFS coutns as a “fast” device when mounted with the “hard” option (the default), but not with the “soft” or “intr” options. This is documented in nfs(5), but could maybe do with a reference. Then there's FUSE filesystems, which seemingly always count as “slow”; even simple operations can return EINTR. I don't know if this is a bug or intentional, so one should probably exercise caution before documenting it.