Skip to content

Fix timers firing up to 1ms early - #755

Open
pctablet505 wants to merge 2 commits into
MagicStack:masterfrom
pctablet505:fix-early-timer-firing
Open

pctablet505 wants to merge 2 commits into
MagicStack:masterfrom
pctablet505:fix-early-timer-firing

Conversation

@pctablet505

@pctablet505 pctablet505 commented Jul 16, 2026 •

Copy link
Copy Markdown

Fixes #739

Under uvloop, asyncio.sleep(n) can return up to ~1 ms before n has actually elapsed. This change pads the timeout passed to libuv by 1 ms, so timers never fire early.

Problem

libuv refreshes loop->time as the monotonic clock floored to whole milliseconds, and uv_timer_start() schedules the callback at loop->time + timeout. Whatever fraction of a millisecond had already passed when the clock was sampled is lost, so the timer comes due early in real time. The issue shows asyncio.sleep(0.1) returning after 0.0991 s.

Example with a 100 ms timer started at real time 1000.9 ms:

loop->time at start due at real time slept
before 1000 (floored) 1000 + 100 = 1100 99.1 ms ❌
after 1000 (floored) 1000 + 100 + 1 = 1101 100.1 ms ✅

Fix

Only the value handed to libuv changes (self.timeout + 1). self.timeout, and therefore TimerHandle.when() / get_when(), still reports the requested deadline. The trade-off is that a timer can fire up to ~1 ms later than before, which is within libuv's 1 ms resolution.

This is a different truncation from #233, which was fixed by rounding the float-to-ms conversion in call_at(). That path is unchanged.

Tests

test_call_later_not_early runs asyncio.sleep(0.01) 300 times and asserts that each one lasts at least the delay, measured with time.monotonic(). The existing test_call_later_rounding (#233) can't catch this, because it measures with the loop's own millisecond-floored clock.

libuv resamples its internal clock as the floor of the current
monotonic time truncated to whole milliseconds, then schedules a
timer for loop->time + timeout. Since the fractional millisecond
already elapsed at the moment of sampling is discarded, the timer can
fire up to ~1ms before the requested delay has actually passed. This
made asyncio.sleep(n) occasionally return slightly under n, as
reported in MagicStack#739.

Pad the timeout handed to uv_timer_start() by 1ms to compensate, while
leaving the reported deadline (get_when()/TimerHandle.when()) as the
originally requested value.
@pctablet505
pctablet505 force-pushed the fix-early-timer-firing branch from 66f1983 to f2b3a0d Compare October 8, 2026 11:35
dex4er added a commit to pyjoyment/Pyjo-Reactor-Uvloop that referenced this pull request Nov 5, 2026
…modules of asyncio

libuv counts a timer in whole milliseconds of a clock that it rounds down,
so a timer of uvloop was due up to a millisecond early by time.monotonic,
which failed the tests of Pyjo.Steps of Pyjoyment now and then.
_Loop.call_later rounds the delay up, as MagicStack/uvloop#755 does.

event_loop_modules stays the one of Pyjo.Reactor.Asyncio: the loop of
uvloop makes no frames of Python below a callback (#7).

Co-Authored-By: Claude Opus 5.5 <[email protected]>
dex4er added a commit to pyjoyment/Pyjo-Reactor-Winloop that referenced this pull request Nov 5, 2026
libuv counts a timer in whole milliseconds from uv_now, its clock
rounded down, and Winloop rounds the delay to them, as uvloop does, so a
timer, as asyncio.sleep, was due up to a millisecond before its time,
where the loop of asyncio is never early: a sleep of 2 ms took 1.5 ms.
call_later of _Loop, which call_at of Winloop calls too, rounds the
delay up to a millisecond and adds the one that the clock loses, as
_Loop of Pyjo.Reactor.Uvloop does, after MagicStack/uvloop#755.

The subtest of Pyjo-Reactor-Uvloop measures with time.perf_counter,
which time.monotonic is on Windows since Python 3.13, and which counted
in the ticks of the system of 15.6 ms before.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
dex4er added a commit to pyjoyment/Pyjo-Reactor-Winloop that referenced this pull request Nov 5, 2026
…ime, and a timer not due before its time (#6)

* Pyjo.Reactor.Winloop: a socket that loops watch, polled by one at a time

libuv of Windows polls a socket with an exclusive request of AFD, which
ends the request of any other loop for the same socket, also of a copy
of it, and that loop polls it again, in a busy loop of C with no event
at all. The workers of Pyjo.Server.Prethread watch the listen sockets of
the manager on Windows, the same sockets in every thread: four idle
loops took 240% of the processors and starved the process and the tests
next to it, with or without the GIL.

_Loop keeps the readers and the writers of each socket, and a registry
of the process has the loops that watch it, the owner that libuv polls
it for, and the loops that run and wait for it. The owner hands it over
to the next one after each of its events, so that the connections go to
every worker in turn, and at the end of its run; a loop changes the
polls of libuv only in its thread. A socket that one loop watches goes
to libuv as before.

Closes #5

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* uv.lock: Pyjoyment of Git main at 1fc984a

Pyjoyment of Git main with pyjoyment/Pyjoyment#550 and
pyjoyment/Pyjoyment#552, the tests of a page of GitHub without its title
in the tutorial and of the servers of Hot and Reload that did not answer
or did not stop.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* uv.lock: Pyjoyment of Git main at 7b09754

Pyjoyment of Git main with pyjoyment/Pyjoyment#553, a sleep of
Pyjo.Steps in its tests on an event loop of libuv, whose timer may be
due a millisecond early, and pyjoyment/Pyjoyment#554, the data of a
connection that the daemon has removed discarded.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Pyjo.Reactor.Winloop: a timer not due before its time

libuv counts a timer in whole milliseconds from uv_now, its clock
rounded down, and Winloop rounds the delay to them, as uvloop does, so a
timer, as asyncio.sleep, was due up to a millisecond before its time,
where the loop of asyncio is never early: a sleep of 2 ms took 1.5 ms.
call_later of _Loop, which call_at of Winloop calls too, rounds the
delay up to a millisecond and adds the one that the clock loses, as
_Loop of Pyjo.Reactor.Uvloop does, after MagicStack/uvloop#755.

The subtest of Pyjo-Reactor-Uvloop measures with time.perf_counter,
which time.monotonic is on Windows since Python 3.13, and which counted
in the ticks of the system of 15.6 ms before.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

uvloop may sleep less than n for asyncio.sleep(n)

1 participant