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.

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

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