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 yselivanov
Recipients germn, gvanrossum, pitrou, r.david.murray, vstinner, yselivanov
Date 2017-09-21.21:41:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506030114.44.0.862085685567.issue31539@psf.upfronthosting.co.za>
In-reply-to
Content
So here's the relevant piece of code:

        end_time = self.time() + self._clock_resolution
        while self._scheduled:
            handle = self._scheduled[0]
            if handle._when >= end_time:
                break
            handle = heapq.heappop(self._scheduled)
            handle._scheduled = False
            self._ready.append(handle)


As I see it, currently we peek into the future time.  Why don't we do 

        end_time = self.time() - self._clock_resolution

to guarantee that timeouts will always be triggered *after* the requested time, not before?  I don't see how the performance can become worse if we do this.
History
Date User Action Args
2017-09-21 21:41:54yselivanovsetrecipients: + yselivanov, gvanrossum, pitrou, vstinner, r.david.murray, germn
2017-09-21 21:41:54yselivanovsetmessageid: <1506030114.44.0.862085685567.issue31539@psf.upfronthosting.co.za>
2017-09-21 21:41:54yselivanovlinkissue31539 messages
2017-09-21 21:41:54yselivanovcreate