test: remove flaky timing dependence from the test suite - #354
Merged
Conversation
Two classes of timing-based test could false-fail on a loaded runner, most visibly Windows Release under parallel CI. Acceptor wait/accept suites (tcp_acceptor.cpp) gated success on a 250ms in-test watchdog that cancelled the operation and asserted it had not fired. On IOCP the wait is served by a background WSAPoll thread that posts a completion; under contention that cross-thread handoff can miss the deadline, tripping the watchdog on a correct build. The guarded operations are all genuinely satisfiable, so a working build completes on its own. run_for / run_one_for suites (io_context.cpp, native_io_context.cpp) asserted elapsed wall-clock time fell within a fixed window. The upper bounds raced the scheduler between two now() samples; the lower bounds only restated that the timeout was honored. Both are removed, keeping the behavioral checks (n == 0, stopped()). In every case a genuine hang now surfaces as a harness timeout, a correct fail signal, instead of a fixed in-test deadline that misfires under load. No library change.
|
An automated preview of the documentation is available at https://354.corosio.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-09-08 20:24:53 UTC |
The forward completion callback runs on a system DNS thread and called work_finished() before post(). work_finished() decrements the scheduler's outstanding-work count and, at zero, wakes run() to return; post() re-increments it. Between the two the count could reach zero, run() could return, and the io_context -- with this resolver service -- could be destroyed before post() ran, leaving svc_ a dangling reference: the intermittent boost.corosio.resolver SEGFAULT seen only on Windows. Post before work_finished so the posted op holds the count above zero across the balance, and cache svc_ because the queued op may free the impl the instant it is posted. Apply the same reorder to the reverse-resolve pool completion and the synchronous GetAddrInfoExW path, which shared the ordering.
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
2 participants
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.
Two classes of timing-based test could false-fail on a loaded runner, most visibly Windows Release under parallel CI.
Acceptor wait/accept suites (tcp_acceptor.cpp) gated success on a 250ms in-test watchdog that cancelled the operation and asserted it had not fired. On IOCP the wait is served by a background WSAPoll thread that posts a completion; under contention that cross-thread handoff can miss the deadline, tripping the watchdog on a correct build. The guarded operations are all genuinely satisfiable, so a working build completes on its own.
run_for / run_one_for suites (io_context.cpp, native_io_context.cpp) asserted elapsed wall-clock time fell within a fixed window. The upper bounds raced the scheduler between two now() samples; the lower bounds only restated that the timeout was honored. Both are removed, keeping the behavioral checks (n == 0, stopped()).
In every case a genuine hang now surfaces as a harness timeout, a correct fail signal, instead of a fixed in-test deadline that misfires under load.
No library change.