Bug 1157908 - Give Gecko thread Looper low priority; r=snorp
☠☠ backed out by 6d0fb655e2e6 ☠ ☠
authorJim Chen <nchen@mozilla.com>
Fri, 24 Apr 2015 14:40:55 -0400
changeset 241028 7164a2488b286057a748e0c412389b3665ecfd94
parent 241027 a12f0f05779c7d020bc130b844129be72a53110c
child 241029 a486dcc9c23367a2c8642daa2f5b5c43e6b0429c
push id28652
push usercbook@mozilla.com
push dateMon, 27 Apr 2015 10:00:58 +0000
treeherdermozilla-central@8aff0d2a7bc7 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerssnorp
bugs1157908
milestone40.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1157908 - Give Gecko thread Looper low priority; r=snorp
ipc/glue/MessagePump.cpp
widget/android/nsAppShell.cpp
--- a/ipc/glue/MessagePump.cpp
+++ b/ipc/glue/MessagePump.cpp
@@ -18,20 +18,16 @@
 #include "nsDebug.h"
 #include "nsServiceManagerUtils.h"
 #include "nsString.h"
 #include "nsThreadUtils.h"
 #include "nsTimerImpl.h"
 #include "nsXULAppAPI.h"
 #include "prthread.h"
 
-#ifdef MOZ_WIDGET_ANDROID
-#include "AndroidBridge.h"
-#endif
-
 #ifdef MOZ_NUWA_PROCESS
 #include "ipc/Nuwa.h"
 #endif
 
 using base::TimeTicks;
 using namespace mozilla::ipc;
 
 NS_DEFINE_NAMED_CID(NS_TIMER_CID);
@@ -100,25 +96,16 @@ MessagePump::Run(MessagePump::Delegate* 
     if (!keep_running_)
       break;
 
     // NB: it is crucial *not* to directly call |aDelegate->DoWork()|
     // here.  To ensure that MessageLoop tasks and XPCOM events have
     // equal priority, we sensitively rely on processing exactly one
     // Task per DoWorkRunnable XPCOM event.
 
-#ifdef MOZ_WIDGET_ANDROID
-    // This processes messages in the Android Looper. Note that we only
-    // get here if the normal Gecko event loop has been awoken above.
-    // Bug 750713
-    if (MOZ_LIKELY(AndroidBridge::HasEnv())) {
-        did_work |= mozilla::widget::GeckoAppShell::PumpMessageLoop();
-    }
-#endif
-
     did_work |= aDelegate->DoDelayedWork(&delayed_work_time_);
 
 if (did_work && delayed_work_time_.is_null()
 #ifdef MOZ_NUWA_PROCESS
     && (!IsNuwaReady() || !IsNuwaProcess())
 #endif
    )
       mDelayedWorkTimer->Cancel();
--- a/widget/android/nsAppShell.cpp
+++ b/widget/android/nsAppShell.cpp
@@ -238,16 +238,25 @@ nsAppShell::ProcessNextNativeEvent(bool 
         js::ProfileEntry::Category::EVENTS);
 
     nsAutoPtr<AndroidGeckoEvent> curEvent;
     {
         MutexAutoLock lock(mCondLock);
 
         curEvent = PopNextEvent();
         if (!curEvent && mayWait) {
+            // This processes messages in the Android Looper. Note that we only
+            // get here if the normal Gecko event loop has been awoken
+            // (bug 750713). Looper messages effectively have the lowest
+            // priority because we only process them before we're about to
+            // wait for new events.
+            if (widget::GeckoAppShell::PumpMessageLoop()) {
+                return true;
+            }
+
             PROFILER_LABEL("nsAppShell", "ProcessNextNativeEvent::Wait",
                 js::ProfileEntry::Category::EVENTS);
             mozilla::HangMonitor::Suspend();
 
             // hmm, should we really hardcode this 10s?
 #if defined(DEBUG_ANDROID_EVENTS)
             PRTime t0, t1;
             EVLOG("nsAppShell: waiting on mQueueCond");