bug#18988: select failure with EINTR in guile-2.0.11

bug#18988: select failure with EINTR in guile-2.0.11

[Chris Vine]

A program of mine using guile-2.0.11 fails whenever a signal occurs
while a call to select is blocking, with this error:

  Backtrace:
  In ice-9/boot-9.scm:
   157: 9 [catch #t #<catch-closure 820f0a0> ...]
  In unknown file:
     ?: 8 [apply-smob/1 #<catch-closure 820f0a0>]
  In ice-9/boot-9.scm:
    63: 7 [call-with-prompt prompt0 ...]
  In ice-9/eval.scm:
   432: 6 [eval # #]
  In ice-9/boot-9.scm:
  2401: 5 [save-module-excursion #<procedure 821fd00 at ice-9/boot-9.scm:4045:3 ()>]
  4052: 4 [#<procedure 821fd00 at ice-9/boot-9.scm:4045:3 ()>]
  In unknown file:
     ?: 3 [load-compiled/vm "/home/chris/.cache/guile/ccache/2.0-LE-4-2.0/home/chris/src/event-loop.scm.go"]
  In /home/chris/src/./event-loop.scm:
   258: 2 [#<procedure 8767350 ()>]
    68: 1 [event-loop-run #<r6rs:record:event-loop>]
  In unknown file:
     ?: 0 [select (5) () () #<undefined> #<undefined>]

  ERROR: In procedure select:
  ERROR: In procedure select: Interrupted system call

According to the mailing list exchange at
http://lists.gnu.org/archive/html/guile-rpc-bugs/2014-05/msg00001.html ,
this was fixed in guile >= 2.0.10.  However it is still present (or back
as a regression) in guile-2.0.11.

The EINTR-safe wrapper mentioned in the mailing list exchange fixes it
for me in user code, but it would be nice if it were not necessary and
guile handled EINTR itself.

bug#18988: select failure with EINTR in guile-2.0.11

[Chris Vine]

On looking at the code in filesys.c, it is evident that EINTR is not
handled by select as described in the documentation, and that there are
three solutions to this:

1.  To do what the documentation says, and to handle EINTR by returning
rather than by throwing a system-error exception ("[select] also returns
if interrupted by a signal").  Pros: it probably matches what people
have been coding to since that is what is currently (but wrongly)
documented as happening; and it still provides an opportunity for a
program relying on a timeout to decide what to do if the system call
returns prematurely.  Cons:  It is very difficult for user code to
restart the call with an appropriately reduced new timeout period
representing the residue of the timeout period - but that is something
users of select must expect anyway because a file descriptor becoming
ready will have the same effect (and there is always the SA_RESTART
flag).

2.  To restart with an appropriately reduced timeout representing the
residue of the timeout period.  Pros: EINTR is handled seamlessly as
if by SA_RESTART.  Cons:  Although linux modifies the timeout argument
on returning to indicate the unexpired period of a timeout, I believe
the BSDs do not (I have no idea what windows does). For OSs that do not
provide this information, there are two sub-choices - behave as in 1
above, or to just restart and accept that the timeout might be much
delayed in the presence of interrupts by wrapping the select call with
SCM_SYSCALL (in theory, on a long timeout with many interrupts, the
timeout may never occur at all).

3.  To correct the documentation but leave select throwing an exception
on an interrupt occuring, by saying in the documentation that rather
than select returning, it throws a system-error exception with errno
set to EINTR.

On balance I would go for 1 above.  I am happy to submit a patch, but
won't do so unless I know that that is the behaviour that is wanted.

bug#18988: select failure with EINTR in guile-2.0.11

[Ludovic Courtès]

Thanks for the report and analysis.  I went ahead and commit d1447c7
clarifies the behavior of ‘select’ in the presence of interruptions by
signals (will be in 2.0.12.)

Ludo’.