Repository navigation
Add an extra tick for explicit timeouts below resolution — to avoid infinite sleeps - #36
Merged
Merged
Conversation
nolar
force-pushed
the
fix-small-timeouts
branch
from
October 14, 2026 14:17
c1ac453 to
1efb8af
Compare
nolar
changed the title
…nfinite sleeps The issue was caused by misalignment of looptime vs. asyncio: the fractional part of the sleep smaller than the resolution (1e-6 by default) was rounded down to 0, causing 0 ticks of the clock, while asyncio clearly expected the time to move beyond that point, which never happened. Now, it will happen — the clock can move slightly beyond the requested timeout, but at most by 1 tick of the resolution. A tricky aspect: sometimes, asyncio requested sleeps with floating point precision errors in them (because of its timeout math), and we cannot add 1x extra tick there, since this would break the precise time movements of looptime. Instead, we split that one sleep by an integer number of ticks as usual, and add 1x extra tick only if the requested timeout is explicitly smaller than the resolution, but greater than zero. In other words, when we are sure that asyncio asks for this tiny sleep, and does not inject it because of the floating point math. The sleeps and timeouts with no fractional parts smaller than the resoltion, should not be affected, as they remain in the integer zone and require no extra ticks. Signed-off-by: Sergey Vasilyev <nolar@nolar.info>
nolar
force-pushed
the
fix-small-timeouts
branch
from
October 14, 2026 14:20
1efb8af to
56d755c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The issue was caused by misalignment of looptime vs. asyncio: the fractional part of the sleep smaller than the resolution (1e-6 by default) was rounded down to 0, causing 0 ticks of the clock, while asyncio clearly expected the time to move beyond that point, which never happened. Now, it will happen — the clock can move slightly beyond the requested timeout, but at most by 1 tick of the resolution.
A tricky aspect: sometimes, asyncio requested sleeps with floating point precision errors in them (because of its timeout math), and we cannot add 1x extra tick there, since this would break the precise time movements of looptime. Instead, we split that one sleep by an integer number of ticks as usual, and add 1x extra tick only if the requested timeout is explicitly smaller than the resolution, but greater than zero. In other words, when we are sure that asyncio asks for this tiny sleep, and does not inject it because of the floating point math.
The sleeps and timeouts with no fractional parts smaller than the resoltion, should not be affected, as they remain in the integer zone and require no extra ticks.
Closes #35