cc: Implement shared worker contexts.

content/common/gpu/client/command_buffer_proxy_impl.cc

Index: content/common/gpu/client/command_buffer_proxy_impl.cc
diff --git a/content/common/gpu/client/command_buffer_proxy_impl.cc b/content/common/gpu/client/command_buffer_proxy_impl.cc
index 53ce2d7ee543787639fe8e1d0d14af7e50d20764..374a2584abbceca18fb873ccda2817d3bd3d2ecb 100644
--- a/content/common/gpu/client/command_buffer_proxy_impl.cc
+++ b/content/common/gpu/client/command_buffer_proxy_impl.cc
@@ -45,10 +45,17 @@ CommandBufferProxyImpl::~CommandBufferProxyImpl() {
   FOR_EACH_OBSERVER(DeletionObserver,
                     deletion_observers_,
                     OnWillDeleteImpl());
-  if (channel_) {
-    channel_->DestroyCommandBuffer(this);
-    channel_ = nullptr;
-  }
+  Destroy();
+}
+
+void CommandBufferProxyImpl::Destroy() {

[piman, 2015/09/09 19:14:22]

The lock needs to be held here. Should this CheckLock()?

+  if (!channel_)
+    return;
+
+  channel_->DestroyCommandBuffer(this);

[Ken Russell (switch to Gerrit), 2015/09/09 06:09:11]

Doesn't DestroyCommandBuffer need to be called on the same thread that created
the CommandBufferProxyImpl so that the IPC route set up by the GpuChannelHost is
torn down correctly? If so, is that guaranteed?

[reveman, 2015/09/09 13:45:23]

Correct. ::Destroy has the same thread usage restrictions as the dtor. In the
case of shared worker contexts this is always the main thread.

An explicit Destroy function makes it possible to always call
DestroyCommandBuffer on the correct thread instead of relying on the last
reference to the ContextProvider to be dropped on the correct thread, which in
the case of shared worker contexts is hard to guarantee in a clean way.

+  channel_ = nullptr;
+  last_state_.error = gpu::error::kLostContext;

[piman, 2015/09/09 19:14:22]

If we lose the context, we have to lose all contexts in the same share group.
This is necessary per spec, and is necessary to avoid resource leaks and races.

leaks: resources are per share group. After a context is lost, it can't send
commands to release its resources. Other clients that use the same share group
most likely don't know about these resources and can't release them on its
behalf. The only way to release these resources is to destroy all contexts in
this share group - by reporting all of them lost.

races: if some contexts report lost but others don't, some clients will try to
recreate whereas others won't. That results in different clients using different
share groups, whereas they believe they do.


If the context is lost on the GPU side, the GPU process ensures it will cause
all contexts to be lost. If the channel is lost, we also ensure all contexts on
the same channel will report being lost.

+  last_state_.context_lost_reason = gpu::error::kGpuChannelLost;
 }
 
 bool CommandBufferProxyImpl::OnMessageReceived(const IPC::Message& message) {