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.
