Question

When do you need to use this type of modified message loop in multithreaded application?

DWORD nWaitCount;
HANDLE hWaitArray[4];
BOOL quit;
int exitCode;
while (!quit)
{
   MSG msg;
   int rc;
   rc = MsgWaitForMultipleObjects(nWaitCount, hWaitArray, FALSE, INFINITE,QS_ALLINPUT);

   if (rc == WAIT_OBJECT_O + nWaitCount)
   {
       while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
       {
        if (msg.message == WM_QUIT)
        {
            quit = TRUE;
            exitCode = msg.wParam;
            break;
        }
        TranslateMessage(&msg);
        DispatchMessage(&msg);
       }
   }
   else if (rc >= WAIT_OBJECT_0 && rc < WAIT_OBJECT_0 + nwaitCount)
   {
       int nlndex = rc - WAIT_OBJECT_0;
   }
   else if (rc >= WAIT_ABANDONED_0 && rc < WAIT_ABANDONED_0+ nWaitCount)
   {
       int nlndex = rc - WAIT_ABANDONED_O;
   }
}

Answer 1

Hopefully never. But it is the kind of code you have to write when you want the UI thread to block on synchronization objects. A UI thread is not permitted to block, Windows prevents you from calling WaitForMultipleObjects(). The reason is that it is very likely to cause deadlock.

The reason for that is COM. COM is everywhere in Windows, the most common examples are the clipboard, drag+drop and the shell dialogs. COM marshals interface method calls made from a worker thread for COM objects that live on the STA (Single Threaded Apartment) by using the message loop. If the STA thread isn’t pumping messages then the call won’t complete. And calls that can’t complete are ingredient number one for deadlock. Add a UI thread that waits for the worker thread to complete and deadlock is assured.

You avoid this kind of code by having a worker thread use PostMessage() to signal the UI thread that something important happened.