summaryrefslogtreecommitdiffstats
path: root/chrome
diff options
context:
space:
mode:
authoramanda@chromium.org <amanda@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-07-13 21:02:00 +0000
committeramanda@chromium.org <amanda@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-07-13 21:02:00 +0000
commit9ee23c5ba23ad61130471514e874ccefcc7ea25c (patch)
treea9fcb7bbd32575c9839ad6dab6a967d44451171d /chrome
parent8abd2aa9413476480e6607aee8293cc62366a1a8 (diff)
downloadchromium_src-9ee23c5ba23ad61130471514e874ccefcc7ea25c.zip
chromium_src-9ee23c5ba23ad61130471514e874ccefcc7ea25c.tar.gz
chromium_src-9ee23c5ba23ad61130471514e874ccefcc7ea25c.tar.bz2
Remove the carbon event dispatcher from the main thread of the plugin process
and replace it with a pump for null events on the plugin thread. This removes a deadlock that the previous code inadvertently created, and is a much more focused solution to the problem. BUG=10809 TEST=none Review URL: http://codereview.chromium.org/155439 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20528 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome')
-rw-r--r--chrome/plugin/plugin_main.cc48
1 files changed, 0 insertions, 48 deletions
diff --git a/chrome/plugin/plugin_main.cc b/chrome/plugin/plugin_main.cc
index 4cc7911..375831a 100644
--- a/chrome/plugin/plugin_main.cc
+++ b/chrome/plugin/plugin_main.cc
@@ -27,47 +27,6 @@
#include "base/global_descriptors_posix.h"
#endif
-#if defined(OS_MACOSX)
-
-// To support Mac NPAPI plugins that use the Carbon event model (i.e., most
-// shipping plugins for MacOS X 10.5 and earlier), we need some way for the
-// Carbon event dispatcher to run, even though the plugin host process itself
-// does not use Carbon events. Rather than give control to the standard
-// Carbon event loop, we schedule a periodic task on the main thread which
-// empties the Carbon event queue every 20ms (chosen to match how often Safari
-// does the equivalent operation). This allows plugins to receive idle events
-// and schedule Carbon timers without swamping the CPU. If, in the future,
-// we remove support for the Carbon event model and only support the Cocoa
-// event model, this can be removed. Note that this approach does not install
-// standard application event handlers for the menubar, AppleEvents, and so on.
-// This is intentional, since the plugin process is not actually an application
-// with its own UI elements--all rendering and event handling happens via IPC
-// to the renderer process which invoked it.
-
-namespace {
-
-const int kPluginUpdateIntervalMs = 20; // 20ms = 50Hz
-
-void PluginCarbonEventTask() {
- EventRef theEvent;
- EventTargetRef theTarget;
-
- theTarget = GetEventDispatcherTarget();
-
- // Dispatch any pending events. but do not block if there are no events.
- while (ReceiveNextEvent(0, NULL, kEventDurationNoWait,
- true, &theEvent) == noErr) {
- SendEventToEventTarget (theEvent, theTarget);
- ReleaseEvent(theEvent);
- }
-
- MessageLoop::current()->PostDelayedTask(FROM_HERE,
- NewRunnableFunction(PluginCarbonEventTask), kPluginUpdateIntervalMs);
-}
-
-}
-#endif
-
// main() routine for running as the plugin process.
int PluginMain(const MainFunctionParams& parameters) {
// The main thread of the plugin services IO.
@@ -120,13 +79,6 @@ int PluginMain(const MainFunctionParams& parameters) {
#endif
}
-#if defined(OS_MACOSX)
- // Spin off a consumer for the native (Carbon) event stream so
- // that plugin timers, event handlers, etc. will work properly.
- MessageLoop::current()->PostDelayedTask(FROM_HERE,
- NewRunnableFunction(PluginCarbonEventTask), kPluginUpdateIntervalMs);
-#endif
-
{
ChildProcess plugin_process(new PluginThread());
#if defined(OS_WIN)