Don't use sync-dispatch in CompositableClient::GetTextureClientRecycler()
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
Attachments
(1 file)
CompositableClient::GetTextureClientRecycler() will synchronously dispatch a task on the ImageBridgeChildThread to create a TextureClientRecycleAllocator.
As per bug 1650352 comment 2 this is causing a deadlock as the ImageBridgeChildThread is now using a background taskqueue rather than a dedicated thread. So if CompositableClient::GetTextureClientRecycler() is also called by any code also using the background taskqueue's threadpool (which is made of a single thread) the task dispatched will never run.
This change was introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1280839 in patch part 2.
I see nothing in the TextureClientRecycleAllocator constructor that would require it to be constructed on a given thread.
It inherits from ITextureClientRecycleAllocator which has thread-safe refcounting.
Also all methods of TextureClientRecycleAllocator are run with a mutex held, this all of it is thread-safe.
The TextureClientRecycleAllocator constructor was last modified in bug 1281456 but it didn't fundamentally modified anything that could relate to thread-safety.
So that synchronous task dispatching doesn't appear to be required.
|
Assignee | |
Comment 1•4 years ago
|
||
Additionally, we make access to mTextureClientRecycler, mHandle and mIsAsync thread-safe as they are accessed and set from different threads
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1ff743b3d002 Don't synchronously dispatch a task to create a TextureClientRecycleAllocator. r=sotaro
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
Description
•