This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients gvanrossum, neologix, vstinner
Date 2014-02-03.18:39:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1391452775.89.0.281844164324.issue20493@psf.upfronthosting.co.za>
In-reply-to
Content
I guess whenever you have a timeout like that it's the product of a bad calculation in the app (wouldn't be the first time that someone multiplied by 1000 instead of dividing to go from milliseconds to seconds :-). So it would be good to catch this in call_later() / call_at() -- when it's caught in <selector>.select() the developer will have a harder time debugging which event had the bad time.

Is there a limit we can set on times that is clearly absurd when real times? E.g. past the year 9999? We should have two numbers: one value below which times will definitely be accepted (even if they may sound a bit absurd), another, higher value above which bad times will definitely be rejected. In between it may depend on the epoch of time.monotonic(), so I don't want to be too precise in the promises here.

I suppose all the related system calls have *some* limit, it's just that only poll and epoll internally use an integer (I suppose 64-bit?) expressing milliseconds, which is a little too close for comfort?

OK, I just played around with the various selector classes on OS X. I only tried values of t that were a power of 2 minus one (starting at 2**65 - 1).

For SelectSelector, I get OverflowError for t >= 18446744073709551615, OSError(EINVAL) for t >= 134217727.

For PollSelector, I get OverflowError for t >= 4194303, never OSError.

For KqueueSelector, I get OverflowError for t >= 18446744073709551615, OSError(EINVAL) for t >= 134217727.

Of all these, 4194303 is the smallest, it's only 2**22-1, i.e. 48 days in the future (and all I know is that 2**21-1 worked -- I don't know about values in between). But even 134217727 (2**27 - 1) is not that large, only about 4 years. I can easily see apps (e.g. calendars) manage real events that far in the future, knowing full well that they won't ever wait that long, but trying to treat all events uniformly.

I now think that the selector classes probably shouldn't have to deal with this (it can't really know when the syscall will raise OSError, and it shouldn't loop), but asyncio should be better behaved. Perhaps it should reject times that are close to the OverflowError limit in call_soon() / call_at(), but silently wait for a shorter period when the selector's select() raises OSError? (If it weren't for the really low limit with poll(), I'd just substitute None, expecting the process to die long before the event fires, but it's not unreasonable to expect a server process to stay up for months.)
History
Date User Action Args
2014-02-03 18:39:35gvanrossumsetrecipients: + gvanrossum, vstinner, neologix
2014-02-03 18:39:35gvanrossumsetmessageid: <1391452775.89.0.281844164324.issue20493@psf.upfronthosting.co.za>
2014-02-03 18:39:35gvanrossumlinkissue20493 messages
2014-02-03 18:39:35gvanrossumcreate