MessagePumpForGpu - reduce potential work processing starvation

base/message_loop/message_pump_win.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/message_loop/message_pump_win.h"
 
 #include <math.h>
 #include <stdint.h>
 
 #include <limits>
@@ skipping 494 matching lines @@
 
     WaitForWork();  // Wait (sleep) until we have work to do again.
   }
 }
 
 void MessagePumpForGpu::WaitForWork() {
   // Wait until a message is available, up to the time needed by the timer
   // manager to fire the next set of timers.
   int delay;
 
+  // TODO(stanisc): crbug.com/596190: Preserve |result| for crash dump analysis
+  // with initial value different from values returned by
+  // MsgWaitForMultipleObjectsEx.
+  DWORD result = static_cast<DWORD>(-1);
+  debug::Alias(&result);
+
   // The while loop handles the situation where on Windows 7 and later versions
   // MsgWaitForMultipleObjectsEx might time out slightly earlier (less than one
   // ms) than the specified |delay|. In that situation it is more optimal to
   // just wait again rather than waste a DoRunLoop cycle.
   while ((delay = GetCurrentDelay()) != 0) {
     if (delay < 0)  // Negative value means no timers waiting.
       delay = INFINITE;
 
-    DWORD result =
-        MsgWaitForMultipleObjectsEx(1, &event_, delay, QS_ALLINPUT, 0);
+    result = MsgWaitForMultipleObjectsEx(1, &event_, delay, QS_ALLINPUT, 0);
     if (result == WAIT_OBJECT_0) {
       // Work available.
       return;
     } else if (result == WAIT_OBJECT_0 + 1) {
-      // Message available. Keep waiting if this message isn't for this thread.
+      // Message available (regardless of whether |event_| is also signalled at
+      // the same time).
+
+      // Break the loop if the work is available - PeekMessage will still be
+      // called outside, in ProcessNextMessage.
+      if (WaitForSingleObject(event_, 0) == WAIT_OBJECT_0)

[brucedawson, 2016/06/03 00:18:30]

Previously this loop would favor window messages or a signaled event. This
changes it to favor signaled events over windows messages. This is okay as an
experiment, but I'm not seeing a clear explanation for why this is likely to be
better.

The risk is that if we favor signaled events then we could potentially starve
the other processes that share this message queue (I think, it's all very
messy).

Note that if work requests were coming in via WM_USER window messages then there
would be stronger guarantees of fairness.

Note that it shouldn't be possible to 'flood' the message queue with windows
messages. Even a high-end gaming mouse probably doesn't send WM_MOUSEMOVE
messages any faster than 250-1,000 Hz, and this loop should be able to remove
them at least 100 times faster than that. If there are signs of starvation due
to excess messages we need to understand that, perhaps by tracking the incoming
message rate.

+        return;
+
+      // Keep waiting if this message isn't for this thread.
       MSG msg;
       if (PeekMessage(&msg, nullptr, 0, 0, PM_NOREMOVE))
         return;
     }
 
     DCHECK_NE(WAIT_FAILED, result) << GetLastError();
   }
 }
 
 bool MessagePumpForGpu::ProcessNextMessage() {
@@ skipping 188 matching lines @@
     if (!filter || it->handler == filter) {
       *item = *it;
       completed_io_.erase(it);
       return true;
     }
   }
   return false;
 }
 
 }  // namespace base