Author vstinner
Recipients eric.snow, georg.brandl, gvanrossum, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-25.22:52:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwYHAQYxg1GZzJj_jRsoeEy2LJjbJr6ZaSw5oKM6VkJgJg@mail.gmail.com>
In-reply-to <CAH_1eM1qBDu_rX8kbjq1pL+Sa+k5PHpefSKTDo4fXp2HB=91mQ@mail.gmail.com>
Content
2014-01-25 Charles-Fran├žois Natali <report@bugs.python.org>:
>> It looks like changing the rounding method doesn't solve anything.
>> selector.select(timeout) may still take less than timeout, so it
>> doesn't give any guarantee.
>
> But what problem does it cause if, once in a while, the call takes less
> than the passed timeout?
> If that's the case, you'll simply perform another loop, an wake up 1ms
> later, that's all.

"perform another loop" is my problem. If possible, I would like
useless calls to the loop. With my latest patch to asyncio, there is
no more useless calls to the loop (at least, not because of a time
rounding issue).

Oh, I forgot to mention that I'm also concerned by the backward
compatibility. Changing how poll and epoll round the timeout changes
the behaviour. It may break applications or maybe change performances
of applications (efficiency or reactivity). Changing the rounding
method in Python 3.3 was not a good idea.

@Charles-Fran├žois: I'm not sure that we are talking about the same
thing. If you still want to change poll and epoll, go ahead. Since the
performance issue has been fixed directly in asyncio, I don't feel the
need of changing the poll or epoll anymore in Python 3.4. Or maybe you
disagree with my change in the asyncio module?
History
Date User Action Args
2014-01-25 22:52:20vstinnersetrecipients: + vstinner, gvanrossum, georg.brandl, pitrou, neologix, python-dev, eric.snow, serhiy.storchaka
2014-01-25 22:52:20vstinnerlinkissue20311 messages
2014-01-25 22:52:20vstinnercreate