🤖 New build scheduled with the buildbot fleet by @gvanrossum for commit 1c641ef 🤖

If you want to schedule another build, you need to add the "🔨 test-with-buildbots" label again.

I’m asking for a buildbot test so we’ll know if any exotic systems have weird or broken perf timers.

A concern I have is, are there systems whose perf timer wraps around within the lifetime of a typical server? That would be a problem…

See also #88494

I’m asking for a buildbot test so we’ll know if any exotic systems have weird or broken perf timers.

Changing time.monotonic() on Windows to use a clock with a better resolution is discussed in #88494 which explains why it was not done yet.

I’m asking for a buildbot test so we’ll know if any exotic systems have weird or broken perf timers.

Okay so all buildbots have passed so that's good.

A concern I have is, are there systems whose perf timer wraps around within the lifetime of a typical server? That would be a problem…

As explained on discord, this isn't a problem as there are no wrapping around issues.

Changing time.monotonic() on Windows to use a clock with a better resolution is discussed in #88494 which explains why it was not done yet.

This PR is about changing asyncio to use high precision clock, not about changing time.monotonic to use higher precision clock. I prefer to keep these two issues separate, someone else would have to investigate for that issue.

@gvanrossum: Trio also always uses time.perf_counter for high precision monotonic clock.

@kumaraditya303 and @vstinner, unfortunately I don't have time to read #88494, but maybe you can? I'd like an approval from @vstinner if he thinks this is okay for asyncio before I merge this.

unfortunately I don't have time to read #88494, but maybe you can? I'd like an approval from @vstinner if he thinks this is okay for asyncio before I merge this.

I don't have time to read the entire #88494, but one thing which stood out from issue is that #85471 was resolved by switching to perf counter on Windows. @vstinner would know more since he worked on the code.
And FWIW Microsoft recommends QueryPerformanceCounter which is what this PR uses.

My understanding of #88494 is that it would fix this and all other uses of time.monotonic and the main thing blocking it is getting a suitable windows 11 development environment available for @vstinner and or @njsmith

This PR looks good to me, but might be worth a docstring change?

I have some worries about using QueryPerformanceCounter() as time.monotonic() on Windows. So far, I'm not convinced that it's safe. The details are in #88494. This issue has a long history and is complicated because it's a complicated problem, and Windows doesn't provide any clock which fits all requirements. Moreover, there are also questions about how clocks behave on Windows 7 and Windows 8, and if Python 3.12 still support these operating systems.

I don't have the bandwidth to dig into this complicated issue. So I cannot review this asyncio change.

Moreover, there are also questions about how clocks behave on Windows 7 and Windows 8, and if Python 3.12 still support these operating systems.

All things aside, CPython 3.9+ does not support Windows 7 so it is irrelevant.

@zooba Do you have any opinion on this?

@zooba Do you have any opinion on this?

No, sorry. If you need one from me, I'll have to schedule some research time next week to figure out what my opinion would be.

No, sorry. If you need one from me, I'll have to schedule some research time next week to figure out what my opinion would be.

Take your time, there is no rush for this. Thank you!

Had a long chat with Steve Dower about this. We found that there's one outright bug in the PR, it doesn't change how loop._clock_resolution is set.

It looks that since at least Windows 7, perf_counter() is monotonic, so no worries about that.

But there's a possibility that _run_once() and run_forever() may end up spinning when the selector rounds the timeout down. We think that the selector on Windows always uses the monotonic clock with a 15.7 msec resolution, but we don't know yet whether it rounds down.

If it does, maybe it's actually correct, on Windows, to use the resolution of the monotonic clock, but only coincidentally.

I think @zooba will add more color.

I had a look at this with Guido and have the following suggestions:

• keep asyncio using time.monotonic by default
• change time.monotonic on Windows to use QueryPerformanceCounter (which has been monotonic and cheap since Windows 8)
• add a MINIMUM_SELECT_TIMEOUT constant set to time.get_clock_info("time").resolution to asyncio/base_events.py and use it here to ensure we don't spinlock

The only weirdness is using the time() resolution instead of monotonic() for the minimum timeout, but it's the best available value (and should handle Windows systems where the clock has been modified). We can pass 0 through without rounding up to the minimum, but if we're going to pass anything that rounds down to 0 (i.e. <1ms) we'd better be sure to execute the waiting task at the other end (in the usual case). Right now, this bit will make sure we do that, but that's also leading to tasks being released early (though likely not in real-world cases), so we could drop the extra constant and rely on the minimum time.

If someone uses await sleep(0.010) in a loop, they should get >=10ms worth of delay rather than consuming 100% CPU in a spinlock.

keep asyncio using time.monotonic by default

Okay, closing. Thanks for the info.