| commit | ff90533c0941ae48cb90a308d987ddd329c29594 | [log] [tgz] |
|---|---|---|
| author | Joe Mason <joenotcharles@google.com> | Fri Jan 23 03:08:56 2026 |
| committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jan 23 03:08:56 2026 |
| tree | 5365e27d0e1b0174d05abfd3ca7b61915bfbbd2c | |
| parent | 2d056feee14fd55c2be5182a7c330e1c515bcc5d [diff] |
Annotate locks in PipelineImpl::RendererWrapper The "WebMediaPlayer_MainThread" MemoryDumpProvider can take a long time to run. I suspect the cause is contention on the lock for RendererWrapper::SharedState, which is taken by GetPipelineStatistics() during a memory dump. The lock semantics are complicated. To help in the investigation, this adds SEQUENCE_CHECKER and EXCLUDED_LOCKS_REQUIRED annotations to make sure the locks are being accessed as described in the SharedState documentation comment. SharedState is now owned by a wrapper class, SharedStateAccessor, that exposes const refs to SharedState on all threads, but only exposes a mutable ref to the media thread. This uncovered two existing issues: * `did_loading_progress` is written from both threads, contradicting the documented semantics. To support this, it's moved to SharedStateAccessor with its own EXCLUSIVE_LOCKS_REQUIRED annotation. * ReportMetadata() writes `suspend_timestamp` without holding the lock. Added the missing lock. Also removed a lock in RenderWrapper::Resume that was shown to be unneeded. Bug: 41419817,450929521 Change-Id: Iefd4c47b8080bf53e808769747601136fab755be Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7506130 Commit-Queue: Joe Mason <joenotcharles@google.com> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/main@{#1573465}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.