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 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.
Bug 1650728 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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.