Author gregory.p.smith
Recipients arigo, giampaolo.rodola, gregory.p.smith, gvanrossum, koobs, neologix, pitrou, sbt, vstinner
Date 2013-12-01.01:10:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385860214.31.0.766015979328.issue18885@psf.upfronthosting.co.za>
In-reply-to
Content
> 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
History
Date User Action Args
2013-12-01 01:10:14gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, arigo, pitrou, vstinner, giampaolo.rodola, neologix, sbt, koobs
2013-12-01 01:10:14gregory.p.smithsetmessageid: <1385860214.31.0.766015979328.issue18885@psf.upfronthosting.co.za>
2013-12-01 01:10:14gregory.p.smithlinkissue18885 messages
2013-12-01 01:10:14gregory.p.smithcreate