summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
diff options
context:
space:
mode:
authorananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-08-25 20:05:45 +0000
committerananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-08-25 20:05:45 +0000
commiteab113f82537b904c52912663d625cb6afefa3b0 (patch)
tree28a488f33fb0f162aa1c1e6b99f20cfc54424bce /chrome/plugin
parent5fe90ea611c57e45d82b1982e600f9d6ca142a98 (diff)
downloadchromium_src-eab113f82537b904c52912663d625cb6afefa3b0.zip
chromium_src-eab113f82537b904c52912663d625cb6afefa3b0.tar.gz
chromium_src-eab113f82537b904c52912663d625cb6afefa3b0.tar.bz2
Revert 24266 - 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 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/173384 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24296 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/plugin')
-rw-r--r--chrome/plugin/plugin_channel.cc19
1 files changed, 0 insertions, 19 deletions
diff --git a/chrome/plugin/plugin_channel.cc b/chrome/plugin/plugin_channel.cc
index 6aa10d4..04d9afc 100644
--- a/chrome/plugin/plugin_channel.cc
+++ b/chrome/plugin/plugin_channel.cc
@@ -73,25 +73,6 @@ 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;