Bustage fix
authorBen Turner <bent.mozilla@gmail.com>
Tue, 09 Feb 2010 16:12:41 -0800
changeset 38108 cba43f45ed9e0ac98543a67127ffdaaaf9866eb3
parent 38107 1fd68671241e6b7aca8ab6d26b843af56534df22
child 38109 425bd6cb3e216fdbea85b1920c0070e0b6abfc5f
push id11617
push usercjones@mozilla.com
push dateFri, 12 Feb 2010 05:46:47 +0000
treeherdermozilla-central@c5ca3076da1b [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
milestone1.9.3a2pre
Bustage fix
ipc/glue/WindowsMessageLoop.cpp
--- a/ipc/glue/WindowsMessageLoop.cpp
+++ b/ipc/glue/WindowsMessageLoop.cpp
@@ -632,17 +632,17 @@ SyncChannel::WaitForNotify()
 
   {
     while (1) {
       MSG msg = { 0 };
       // Don't get wrapped up in here if the child connection dies.
       {
         MutexAutoLock lock(mMutex);
         if (!Connected()) {
-          return;
+          return true;
         }
       }
 
       // Wait until we have a message in the queue. MSDN docs are a bit unclear
       // but it seems that windows from two different threads (and it should be
       // noted that a thread in another process counts as a "different thread")
       // will implicitly have their message queues attached if they are parented
       // to one another. This wait call, then, will return for a message
@@ -699,27 +699,29 @@ SyncChannel::WaitForNotify()
 
   // Before returning we need to set a hook to run any deferred messages that
   // we received during the IPC call. The hook will unset itself as soon as
   // someone else calls GetMessage, PeekMessage, or runs code that generates
   // a "nonqueued" message.
   ScheduleDeferredMessageRun();
 
   SyncChannel::SetIsPumpingMessages(false);
+
+  return true;
 }
 
-void
+bool
 RPCChannel::WaitForNotify()
 {
   mMutex.AssertCurrentThreadOwns();
 
   if (!StackDepth()) {
     NS_ASSERTION(!StackDepth(),
         "StackDepth() is 0 in a call to RPCChannel::WaitForNotify?");
-    return;
+    return true;
   }
 
   MutexAutoUnlock unlock(mMutex);
 
   // Initialize global objects used in deferred messaging.
   Init();
 
   // IsSpinLoopActive indicates modal UI is being displayed in a plugin. Drop
@@ -728,26 +730,26 @@ RPCChannel::WaitForNotify()
   // received an in-call request from child, so return from WaitForNotify.
   // We'll step back down into the spin loop on the next WaitForNotify call.
   // If the spin loop returns false, the child's modal loop has ended, so
   // drop down into "normal" deferred processing until the next reply is
   // received. Note, spin loop can cause reentrant race conditions, which
   // is expected.
   if (RPCChannel::IsSpinLoopActive()) {
     if (SpinInternalEventLoop()) {
-      return;
+      return true;
     }
 
     // Coming out of spin loop after a modal loop ends, we can't drop into
     // deferred processing on the assumption that MsgWaitForMultipleObjects
     // will get signaled with gEventLoopMessage - messages may have already
     // been received and stored in mPending & mOutOfTurnReplies. So we check
     // various stacks to figure out if we should fall through or just return.
     if (IsMessagePending()) {
-      return;
+      return true;
     }
   }
   
   // Setup deferred processing of native events while we wait for a response.
   NS_ASSERTION(!SyncChannel::IsPumpingMessages(),
                "Shouldn't be pumping already!");
   SyncChannel::SetIsPumpingMessages(true);
   HHOOK windowHook = SetWindowsHookEx(WH_CALLWNDPROC, CallWindowProcedureHook,
@@ -801,22 +803,22 @@ RPCChannel::WaitForNotify()
         ScheduleDeferredMessageRun();
         
         // Spin the internal dispatch message loop during calls to WaitForNotify
         // until the child process tells us the modal loop has closed. A return
         // of true indicates gEventLoopMessage was received, exit out of
         // WaitForNotify so we can deal with it in RPCChannel.
         RPCChannel::EnterModalLoop();
         if (SpinInternalEventLoop())
-          return;
+          return true;
 
         // See comments above - never assume MsgWaitForMultipleObjects will
         // get signaled.
         if (IsMessagePending())
-          return;
+          return true;
 
         // We drop out of our inner event loop after the plugin has relinquished
         // control back to the shim, but the ipdl call has yet to return, so reset
         // our hook in case and continue waiting on gEventLoopMessage.
         windowHook = SetWindowsHookEx(WH_CALLWNDPROC, CallWindowProcedureHook,
                                       NULL, gUIThreadId);
         NS_ASSERTION(windowHook, "Failed to set proc hook on the rebound!");
 
@@ -846,28 +848,28 @@ RPCChannel::WaitForNotify()
 
   // Before returning we need to set a hook to run any deferred messages that
   // we received during the IPC call. The hook will unset itself as soon as
   // someone else calls GetMessage, PeekMessage, or runs code that generates
   // a "nonqueued" message.
   ScheduleDeferredMessageRun();
 
   SyncChannel::SetIsPumpingMessages(false);
+
+  return true;
 }
 
 void
 SyncChannel::NotifyWorkerThread()
 {
   mMutex.AssertCurrentThreadOwns();
   NS_ASSERTION(gUIThreadId, "This should have been set already!");
   if (!PostThreadMessage(gUIThreadId, gEventLoopMessage, 0, 0)) {
     NS_WARNING("Failed to post thread message!");
   }
-
-  return true;
 }
 
 void
 DeferredSendMessage::Run()
 {
   AssertWindowIsNotNeutered(hWnd);
   if (!IsWindow(hWnd)) {
     NS_ERROR("Invalid window!");