Add gpu command buffer support for loseContextCHROMIUM

content/common/message_router.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/common/message_router.h"
 
 #include "ipc/ipc_message.h"
 
 namespace content {
 
@@ skipping 28 matching lines @@
     return OnControlMessageReceived(msg);
 
   return RouteMessage(msg);
 }
 
 bool MessageRouter::RouteMessage(const IPC::Message& msg) {
   IPC::Listener* listener = routes_.Lookup(msg.routing_id());
   if (!listener)
     return false;
 
-  listener->OnMessageReceived(msg);
-  return true;
+  return listener->OnMessageReceived(msg);

[Justin Novosad, 2013/06/21 18:24:11]

This is to prevent an IPC deadlock between the renderer and GPU processes.  In
the case where a gpu context is lost during SyncFlush
listener->OnMessageReceived(msg) will return false, and we need to propagate the
failure to the caller ( GpuChannel::HandleMessage() in this case) to ensure that
a sync response is sent back.

[piman, 2013/06/21 19:05:05]

This is used in many places, for many different channels. The contract is that
RouteMessage only returns false if there's no receiver. If there is, the
receiver (in this case, GpuCommandBufferStub) is responsible for sending the
error reply.

I think changing this will have a lot more impact than just the GPU process. I'm
not opposed to the change of semantics - it makes sense - but this needs to be
done in a separate change, while auditing/fixing all users so that we don't send
2 replies or something.

The alternative is to fix GpuCommandBufferStub::OnMessageReceived to send an
error reply if it early returns false.

Also, is the problem actually happening, still? In r206264 I changed
GetStateFast to not call MakeCurrent, which also means it won't return false, so
FlushSync shouldn't block. That said, there's a couple of other calls that
might.

 }
 
 }  // namespace content