1650728 - Don't use sync-dispatch in CompositableClient::GetTextureClientRecycler()

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Jean-Yves Avenard [:jya]]

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.

Comment 1

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1650728 - Don't synchronously dispatch a task to create a TextureClientRecycleAllocator. r?sotaro

Additionally, we make access to mTextureClientRecycler, mHandle and mIsAsync thread-safe as they are accessed and set from different threads

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ff743b3d002
Don't synchronously dispatch a task to create a TextureClientRecycleAllocator. r=sotaro

Comment 3

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/1ff743b3d002