Add gpu command buffer support for loseContextCHROMIUM

content/common/message_router.cc

Index: content/common/message_router.cc
diff --git a/content/common/message_router.cc b/content/common/message_router.cc
index f73e6543eb4e5b5ecc80096bfa9f6bc28fa2938f..ece9304f52e96242a9f6412e339b3ec98e99ab5f 100644
--- a/content/common/message_router.cc
+++ b/content/common/message_router.cc
@@ -46,8 +46,7 @@ bool MessageRouter::RouteMessage(const IPC::Message& msg) {
   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