Repository navigation
test: check the tool concurrency limit without a timing margin - #226
Open
SizzleUnrlsd wants to merge 2 commits into
Open
SizzleUnrlsd wants to merge 2 commits into
SizzleUnrlsd wants to merge 2 commits into
Conversation
The three timed fake tools each locked the timeline and wrote their run themselves. Timeline::record does it in one place, so that recording a run can also wake a test waiting for it.
The check compared end times: the limited tool, 3 x 200 ms, had to be done after the other tool, 3 x 150 ms, a 150 ms margin. On GitHub's macOS runners a sleep or a worker is sometimes that late: since 2026-10-01 the check failed 8 times in about 100 macOS attempts, with no change to the scheduler. Each run of the limited tool now waits for the other tool to be done with every file, and throws if it is not after 10 s. The check is that no tool failed: it holds when the other tool runs while the limited one holds its worker, and fails when the scheduler makes it wait.
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
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.
Closes #225.
tool_scheduling_testschecked that a tool limited to one run at a time does not keep the other tools waiting. It did so by comparing end times, with a 150 ms margin. Since the check was added on 2026-10-01, it failed 8 times in about 100 macOS attempts on GitHub's runners: 6 onmacos-14and 2 onmacos-15. The last failure was onmain, after #223.Changes
test:the three timed fake tools record their runs throughTimeline::record, which wakes a test waiting for runs. This changes no check.test:the limited tool now waits instead of racing.failedTools().empty(). It holds when the other tool runs while the limited one holds its worker. It fails when the scheduler makes the other tool wait.The 10 s limit is still a time bound. It is about 20 times the expected wait of 450 ms, against a 150 ms margin before.
Verification
On macOS (8 cores),
ctrace_tool_scheduling_testswas built frommainand from this branch.main. The test runs at background priority (taskpolicy -b), where macOS coalesces timers, so sleeps overrun as they do on the runners.runOnPoolso that each lane waits for the previous one makes the new check fail, after 30 s: each of the three limited runs waits 10 s. The change was reverted.scripts/format-check.shpasses with clang-format 20.Not changed
"the other files are analyzed while a slow file is" uses the same stopwatch, with a 550 ms margin. It has never failed on CI. Under background priority and load, it failed 9 times in 20 runs on
main. If it starts failing on CI, it can be fixed the same way in a follow-up.