MSE-in-Workers: Cross-thread registry with stubbed attachment #25609
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.
Introduces a concrete CrossThreadMediaSourceAttachment with minimum
implementation necessary to enable worker thread MediaSource object URL
creation. To enable registration of worker-thread MediaSource object
URLs, which is inherent in the createObjectURL implementation, updates
MediaSourceRegistryImpl to perform registration and unregistration while
holding a mutex in the singleton, main-thread-owned, registry instance.
Mutexes previously were thought unusable for this, but that was due to
the registry previously using an Oilpan HeapHashMap bound to the main
thread's Oilpan heap. The current registry now uses a non-Oilpan
HashMap, so any thread can update the singleton so long as such
accesses or updates are mutex-protected. Also, using cross-thread task
posting to perform these tasks led to complex races whose solution is
much simpler using the mutex approach herein. See
CrossThreadMediaSourceAttachment::Unregister() for more detail.
Includes a necessary update which makes both types of attachments manage
the registered media source in appropriate Oilpan type: the cross thread
attachment must hold that reference as CrossThreadPersistent. The URL
registry implementation already unregisters all entries created on an
execution context if that context is destroyed, so this
CrossThreadPersistent registry entry will not outlive the worker
thread's context. See PublicURLManager::ContextDestroyed() for where
that logic exists already. Rationale for not also making the
SameThreadMediaSourceAttachment use a CrossThreadPersistent type is that
such type introduces a new root in all Oilpan heaps, and resulting
performance hit can be avoided by just using regular Persistents for
same thread attachments' |registered_media_source_|.
Includes new web_tests that exercise basic worker context MediaSource
construction, object URL creation and revocation (with revocation of
worker MediaSource object URL also tested on main thread). Starting an
attachment to a worker MediaSource is also tested, but is currently
expected by the test to fail until upcoming
CrossThreadMediaSourceAttachment changes land.
BUG=878133
Change-Id: I367b6610da9aca3aca7c78f4a11f571e48afc6c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2407075
Reviewed-by: Will Cassella <cassew@google.com>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#810002}