Repository navigation
Move the gc disabling to looptime's chronometers - #1335
Merged
Merged
Conversation
nolar
commented
Oct 5, 2026
nolar
force-pushed
the
gc-disable-in-looptime
branch
from
October 5, 2026 12:16
56fb937 to
1b0f34e
Compare
nolar
referenced
this pull request
Oct 5, 2026
Due to new three tests, another completely unrelated test (`test_threadsafe_indeed_works()`) started to fail unusually: only in Python 3.12 full-auth; works fine in other 3.12 modes and other full-auth versions — but 100% reproducible in CI and in CI only (not locally). Experiments have shown that the issue happens only when all three tests are active (1+2+3), while the test run passes with only one or two tests (1+2, 2+3, 1+3). Time measurements indicated that the extra time (≈0.13s) was spent on operations so routine that they were not even suspected: exiting a function or adding an item to a list, not in the actual thread starting or something resource-intense. Besides, simple time measurements themselves caused the tests to pass sometimes. The only suspicion was that something was happening under the hood at these moments, and the garbage collection was the number one candidate (in the absence of any parallel/concurrent activities). Probably, the amount of garbage accumulated from all tests was anyway huge, and adding three more tests pushed it beyond the threshold, which accidentally caused the garbage collection in these particular real-clock tests (previously, probably happened in other tests that did not notice anything). Just a sequence of accidents. Either way, enforcing the garbage collection before the test and disabling the garbage collection during the real-clock tests fixed the issue. Pure luck. Signed-off-by: Sergey Vasilyev <nolar@nolar.info>
A rework of an issue fixed in c1e1462, but the fix is now a part of the default behaviour of looptime's chronometers. Signed-off-by: Sergey Vasilyev <nolar@nolar.info>
nolar
force-pushed
the
gc-disable-in-looptime
branch
from
October 12, 2026 12:50
1b0f34e to
74cf7ea
Compare
nolar
marked this pull request as ready for review
October 12, 2026 12:51
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.
A rework of an issue fixed in c1e1462, but the fix is now a part of the default behaviour of looptime's chronometers.
For clarity: it is not proven that the issue was caused by garbage collection, it is just the most viable explanation. It is also not proven that disabling the gc actually fixed the issue. As experiments show, the mere
import gcon the module level already fixes the bug — probably by shifting the gc point earlier/later but outside of the chronometer. Even a switch to looptime's wip branch in this PR, which also fixes the issue, might actually fix it becauseimport gchappens deep there and changes the balance. However, let this "fix" be — as it at least seems viable, despite unproven.