Repository navigation
iOS: Serialise CADisplayLink access in VSyncClient tests - #190335
Conversation
There was a problem hiding this comment.
Code Review
This pull request refactors VSyncClientTests.swift to run tests asynchronously and dispatches interactions with VSyncClient and CADisplayLink to the task runner's thread to prevent race conditions. Feedback highlights that replacing DispatchSemaphore with an unbounded AsyncStream await in releasesLinkOnInvalidation removes the timeout protection, making the test susceptible to infinite hangs in CI if the display link fails to fire. A timeout mechanism using TaskGroup is suggested to mitigate this.
VSyncClientTests were reaching into the client's CADisplayLink from the
test thread, reading properties like isPaused, calling onDisplayLink
directly, inspecting the frame rate range, etc. However, VSyncClient
registration, vsync callbacks, and invalidation run on the dedicated
worker thread it was handed as a task runner. CADisplayLink is not
thread-safe, so this was an unsynchronised data race between the code
running on the test thread and the code running on the worker.
VSyncClient is built around the assumption that its display link is only
ever referenced on its task runner's thread. Right now tests violate
that invariant. While this isn't actively buggy at the moment, it's not
safe to write the tests this way.
This forces every interaction with the CADsiaplyLink through a new run()
helper that dispatches onto the runner and returns the result. Test
assertions remain on the test thread. I've moved the object-lifetime
tests off the autoreleasepool and onto the sam async model. We also
migrate to AsyncStream for the vsync signal and a run {} barrier for
registration/flushing. It scopes the client's only strong reference to a
nested func so we release deterministically on return. It also means we
get rid of the blocking code altogether.
Issue: flutter#181684
Issue: flutter#112232
685ea96 to
9d54516
Compare
| threadTaskRunner.postTask { | ||
| client.await() | ||
| } | ||
| await threadTaskRunner.run { client.await() } |
There was a problem hiding this comment.
nit: I think VsyncClient.await is thread-safe because https://developer.apple.com/documentation/quartzcore/cadisplaylink/ispaused is thread-safe?
There was a problem hiding this comment.
You're right; either approach is correct for this one call site, but I think from a readability/maintainability point of view it's safest to follow the rule I added at the top of the file in the TaskRunner.run() docs, that all interaction with it go through TastRunner.run().
People constantly copy-paste code from one test to another then tweak it, so all interaction with it being via TaskRunner.run reduces the risk of people messing up, and also means readers don't need to reason carefully/dig into the implementation details of each call on it to figure out thread safety. It's also a test, so an extra thread hop is super cheap, not something we need to worry about.
|
|
||
| #expect(vsyncSignal.wait(timeout: .now() + 1.0) == .success) | ||
| // Wait for the display link to deliver its first vsync on the runner's thread. | ||
| let vsync = await vsyncSignals.next(timeout: 1.0) |
There was a problem hiding this comment.
nit: maybe use prefix(1) and add @Test(.timeLimit(.minutes(1)) to the test?
There was a problem hiding this comment.
Will take a look; but when I tried in a previous PR it mentioned .timeLimit required iOS 16+.
There was a problem hiding this comment.
Looking at https://developer.apple.com/documentation/testing/timelimittrait this requires iOS 16+ but our code is iOS 15 compatible.
|
An existing Git SHA, To re-trigger presubmits after closing or re-opeing a PR, or pushing a HEAD commit (i.e. with |
…12406) Manual roll Flutter from e52f01c920ad to b766512c65d8 (42 revisions) Manual roll requested by [email protected] flutter/flutter@e52f01c...b766512 2026-08-04 [email protected] Roll Dart SDK from 2a799a2404e9 to 9859c0a39adb (4 revisions) (flutter/flutter#190521) 2026-08-04 [email protected] Revert: iOS: Eliminate use of IOSContextNoop in platform view tests (flutter/flutter#190501) 2026-08-04 [email protected] [Impeller] Enable ETC2/ASTC LDR/BC texture compression features at Vulkan device creation (flutter/flutter#189303) 2026-08-03 [email protected] Remove openglessdf from impeller_unittests. (flutter/flutter#190469) 2026-08-03 [email protected] [web] Unify image decoding and codecs on CanvasKit and Skwasm (flutter/flutter#188573) 2026-08-03 [email protected] iOS: Eliminate use of IOSContextNoop in platform view tests (flutter/flutter#190419) 2026-08-03 [email protected] Add path rendering benchmarks (flutter/flutter#188654) 2026-08-03 [email protected] Add windows platform support for primitive_shape_test integration test (flutter/flutter#190464) 2026-08-03 [email protected] Roll Skia from 958c1c1921a1 to a08d918ebd6a (3 revisions) (flutter/flutter#190467) 2026-08-03 [email protected] tests: add --ios-runtime param (flutter/flutter#190414) 2026-08-03 [email protected] iOS: Remove the synchronous first-frame wait (flutter/flutter#190432) 2026-08-03 [email protected] iOS: Eliminate the Impeller/Skia backend selection params (flutter/flutter#190416) 2026-08-03 [email protected] iOS,macOS: Use @autoclosure in Logger (flutter/flutter#190417) 2026-08-03 [email protected] tools: Support FLUTTER_HOST_ARCH in update_dart_sdk scripts (flutter/flutter#190421) 2026-08-03 [email protected] iOS: Hardcode rendering API to Metal in tests (no-op) (flutter/flutter#190422) 2026-08-03 [email protected] a11y: Map disabled/read-only semantics to AX node restriction (flutter/flutter#190353) 2026-08-03 [email protected] [Infra] Replace defunct umbrella template with Wasm issue form (flutter/flutter#190471) 2026-08-03 [email protected] Roll Skia from abecb0dc02c1 to 958c1c1921a1 (4 revisions) (flutter/flutter#190459) 2026-08-03 [email protected] Roll Dart SDK from 65b163be2485 to 2a799a2404e9 (3 revisions) (flutter/flutter#190454) 2026-08-03 [email protected] Roll Skia from 68efb3f2ad16 to abecb0dc02c1 (1 revision) (flutter/flutter#190443) 2026-08-03 [email protected] Roll Packages from 5351d8c to ac87e65 (4 revisions) (flutter/flutter#190441) 2026-08-03 [email protected] Roll Skia from 5a761eb826c1 to 68efb3f2ad16 (1 revision) (flutter/flutter#190440) 2026-08-03 [email protected] Roll Skia from 4c9f8b4805e2 to 5a761eb826c1 (1 revision) (flutter/flutter#190437) 2026-08-03 [email protected] [macOS] Resume app lifecycle on becomeActive to avoid frozen UI after occlusion (flutter/flutter#188772) 2026-08-03 [email protected] Roll Skia from 39cda9d6d7d2 to 4c9f8b4805e2 (6 revisions) (flutter/flutter#190426) 2026-08-03 [email protected] Roll Skia from df13bfb5a54e to 39cda9d6d7d2 (2 revisions) (flutter/flutter#190425) 2026-08-02 [email protected] iOS: Serialise CADisplayLink access in VSyncClient tests (flutter/flutter#190335) 2026-08-02 [email protected] Roll Skia from 32329e5643b5 to df13bfb5a54e (1 revision) (flutter/flutter#190394) 2026-08-02 [email protected] [Impeller] Skip binding dead-code-eliminated resources on Metal (flutter/flutter#190040) 2026-08-01 [email protected] [Flutter GPU] Raise Dart errors for invalid render pipelines and memoize per-draw pipeline state (flutter/flutter#189899) 2026-08-01 [email protected] Revert "Improve non rect platform view rendering (#182662)" (flutter/flutter#190003) 2026-08-01 [email protected] Roll Skia from ebf50520d720 to 32329e5643b5 (1 revision) (flutter/flutter#190389) 2026-08-01 [email protected] Roll Skia from f73c4510d12d to ebf50520d720 (6 revisions) (flutter/flutter#190376) 2026-07-31 [email protected] Primitive shape integration test (flutter/flutter#190368) 2026-07-31 [email protected] Eliminate some early returns in uber_sdf.frag to fix broken UberSDF AA on Windows (flutter/flutter#190260) 2026-07-31 [email protected] chore: swiftshader mirrored + llvm16 (flutter/flutter#181225) 2026-07-31 [email protected] [web] Remove in-repo agent documentation (flutter/flutter#190326) 2026-07-31 [email protected] [windows]: Uses offscreen MSAA when implicit msaa isn't available. (flutter/flutter#190256) 2026-07-31 [email protected] flutter_tools: Use new FileSystemExtension from devtools (flutter/flutter#190360) 2026-07-31 [email protected] Roll Dart SDK from c3acfc2479f6 to 65b163be2485 (1 revision) (flutter/flutter#190358) 2026-07-31 [email protected] Use devicectl for screenshots on Xcode 27, remove idevicescreenshot artifact (flutter/flutter#189091) 2026-07-31 [email protected] Roll Skia from 7ef86a5b0eb9 to f73c4510d12d (1 revision) (flutter/flutter#190352) If this roll has caused a breakage, revert this CL and stop the roller ...
VSyncClientTests were reaching into the client's CADisplayLink from the test thread, reading properties like isPaused, calling onDisplayLink directly, inspecting the frame rate range, etc. However, VSyncClient registration, vsync callbacks, and invalidation run on the dedicated worker thread it was handed as a task runner. CADisplayLink is not thread-safe, so this was an unsynchronised data race between the code running on the test thread and the code running on the worker.
VSyncClient is built around the assumption that its display link is only ever referenced on its task runner's thread. Right now tests violate that invariant. While this isn't actively buggy at the moment, it's not safe to write the tests this way.
This forces every interaction with the CADsiaplyLink through a new run() helper that dispatches onto the runner and returns the result. Test assertions remain on the test thread. I've moved the object-lifetime tests off the autoreleasepool and onto the sam async model. We also migrate to AsyncStream for the vsync signal and a run {} barrier for registration/flushing. It scopes the client's only strong reference to a nested func so we release deterministically on return. It also means we get rid of the blocking code altogether.
Issue: #181684
Issue: #112232
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.