Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)

[Jim Rees <rees@umich.edu>]

Trond Myklebust wrote:

  > I would certainly be good if we could delegation the documentation.  But I
  > couldn't find anything in signal(7) that seemed particularly relevant. Which
  > bit were you thinking of?
  > 
  
  The table which lists the posix signals, and which indicates whether they
  are fatal not (i.e. what ‘action’ they cause).  The same page also
  explains signal blocking and signal handling, which could also be
  helpful..

This seems the relevant part to me, assuming nfs system calls are considered
"slow":

           * 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 defini‐
             tion.)  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).

Here's Neil's description:

>>> "A process that is waiting for a reply for an NFS server can be killed
>>> by any signal which would normally kill the process.  If a signal would not
>>> normally kill the process (i.e. it is caught or ignored) then that signal
>>> will not abort and NFS request".

So assuming nfs system calls honor the SA_RESTART flag, I think these
behaviors are the same?