Provide task runner to GLES2Impl / CommandBuffer at creation

gpu/command_buffer/client/gles2_implementation.cc

Index: gpu/command_buffer/client/gles2_implementation.cc
diff --git a/gpu/command_buffer/client/gles2_implementation.cc b/gpu/command_buffer/client/gles2_implementation.cc
index 1098a4030e0e60e9941e2b3b40fc4a984c717030..c4c77e6bf9ba518a4338522754153839a8146680 100644
--- a/gpu/command_buffer/client/gles2_implementation.cc
+++ b/gpu/command_buffer/client/gles2_implementation.cc
@@ -133,7 +133,8 @@ GLES2Implementation::GLES2Implementation(
     bool bind_generates_resource,
     bool lose_context_when_out_of_memory,
     bool support_client_side_arrays,
-    GpuControl* gpu_control)
+    GpuControl* gpu_control,
+    scoped_refptr<base::SingleThreadTaskRunner> task_runner)

[piman, 2016/08/25 22:51:02]

In what way is this task runner meant to be used? I see 2 problems:
1- GLES2Implementation is used in contexts where there is no task runner on the
client thread. For example on the worker thread, as well as in the EGL
implementation for conformance tests and for skia tests.
2- we use the GLES2Implementation on multiple threads, with a lock. This
requires that any task that will use the GLES2Implementation holds the lock
while doing so. So, the client is required to hold that lock when making calls,
and the CommandBufferProxyImpl also takes the lock when executing posted tasks
which would call into the GLES2Implementation - see
CommandBufferProxyImpl::SetLock and uses of that lock. If the
GLES2Implementation is going to post tasks, it will need to take that lock in
those posted tasks, so it will need to be made aware of it.

     : helper_(helper),
       transfer_buffer_(transfer_buffer),
       chromium_framebuffer_multisample_(kUnknownExtensionStatus),