MessagePumpForGpu - reduce potential work processing starvation

base/message_loop/message_pump_win.cc

Index: base/message_loop/message_pump_win.cc
diff --git a/base/message_loop/message_pump_win.cc b/base/message_loop/message_pump_win.cc
index ac54788539cb062da639e4338fe7b430c85b4449..46c4f621a3ff96a607084d4e4f601119b696865b 100644
--- a/base/message_loop/message_pump_win.cc
+++ b/base/message_loop/message_pump_win.cc
@@ -512,6 +512,12 @@ void MessagePumpForGpu::WaitForWork() {
   // 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
@@ -520,13 +526,20 @@ void MessagePumpForGpu::WaitForWork() {
     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;