homepage

> I've always had an implicit understanding that calls with timeouts may, for whatever reason, return sooner than requested (or later!), and the most careful approach is to re-check the clock again.
exactly. at the system call level you can be interrupted. re-checking the clock is the right thing to do if the elapsed time actually matters.
> If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.
We should go ahead and retry for the user for select/poll/epoll/kqueue. If they care about being able to break out of that low level call due to a signal, they should set a signal handler which raises an exception. I have *never* seen code intentionally get an EINTR exception from a select or poll call and have often seen code tripped up because it or a library it was using forgot to handle it.
We're a high level language: Lets be sane by default and do the most desirable thing for the user. Retry the call internally with a safely adjusted timeout:
 new_timeout = min(original_timeout, time_now-start_time)
 if new_timeout <= 0:
 return an empty list # ie: the system clock changed
 retry the call with new_timeout