Make sure sub-pump is running (if needed) before handling a windows task

I still need to performance test this, and carefully check all paths, but
I think this is a reasonable shot at the fix.

bug=4808

r=darin
Review URL: http://codereview.chromium.org/13733

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6898 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 11 insertions, 5 deletions

diff --git a/base/message_pump_win.cc b/base/message_pump_win.cc
index 7ada5eb7..ca5baa8 100644
--- a/base/message_pump_win.cc
+++ b/base/message_pump_win.cc
@@ -380,13 +380,19 @@ bool MessagePumpForUI::ProcessPumpReplacementMessage() {
          msg.hwnd != message_hwnd_);
 
   // Since we discarded a kMsgHaveWork message, we must update the flag.
-  InterlockedExchange(&have_work_, 0);
+  int old_have_work = InterlockedExchange(&have_work_, 0);
+  DCHECK(old_have_work);
 
-  // TODO(darin,jar): There is risk of being lost in a sub-pump within the call
-  // to ProcessMessageHelper, which could result in no longer getting a
-  // kMsgHaveWork message until the next out-of-band call to ScheduleWork.
+  // We don't need a special time slice if we didn't have_message to process. 
+  if (!have_message)
+    return false;
 
-  return have_message && ProcessMessageHelper(msg);
+  // Guarantee we'll get another time slice in the case where we go into native
+  // windows code.   This ScheduleWork() may hurt performance a tiny bit when
+  // tasks appear very infrequently, but when the event queue is busy, the
+  // kMsgHaveWork events get (percentage wise) rarer and rarer.
+  ScheduleWork();
+  return ProcessMessageHelper(msg);
 }
 
 //-----------------------------------------------------------------------------