This CL ensures that plugins always peek in the context of outgoing sync calls.

I will be watching the reliability test runs closely for any crashes which creep in due to reentrancies into plugins caused by this CL. 

This fixes bug http://code.google.com/p/chromium/issues/detail?id=15985

It is a touch tricky to implement a test case for this. Will add one hopefully in a subsequent CL

Bug=15985
Test=Covered by UI test

Review URL: http://codereview.chromium.org/173211

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24266 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 19 insertions, 0 deletions

diff --git a/chrome/plugin/plugin_channel.cc b/chrome/plugin/plugin_channel.cc
index 04d9afc..6aa10d4 100644
--- a/chrome/plugin/plugin_channel.cc
+++ b/chrome/plugin/plugin_channel.cc
@@ -73,6 +73,25 @@ bool PluginChannel::Send(IPC::Message* msg) {
     LOG(INFO) << "sending message @" << msg << " on channel @" << this
               << " with type " << msg->type();
   }
+
+  if (msg->is_sync()) {
+    IPC::SyncMessage* sync_msg = static_cast<IPC::SyncMessage*>(msg);
+    // Clear the existing pump messages event if any in the message. This
+    // is because we won't be relying on this event being set to decide whether
+    // to pump messages or not.
+    sync_msg->set_pump_messages_event(NULL);
+
+    // Signal that the channel should continue to pump messages while it waits
+    // for the sync call to complete. This is to ensure that the following
+    // scenario does not result in a deadlock.
+    // 1. Plugin1 issues a sync request to the renderer
+    // 2. The renderer then issues a sync request to plugin2.
+    // 3. Plugin2 then dispatches a native message to plugin1
+    // If we don't pump messages from Plugin1, then it would cause a deadlock
+    // as the three processes above are waiting for each other.
+    sync_msg->EnableMessagePumping();
+  }
+
   bool result = PluginChannelBase::Send(msg);
   in_send_--;
   return result;