"window procedure" of a newly created thread without window

Question

Hi,

I want to create a thread for some db writes that should not block the ui in case the db is not there. For synchronizing with the main thread, I'd like to use windows messages. The main thread sends the data to be written to the writer thread.

Sending is no problem, since CreateThread returns the handle of the newly created thread. I thought about creating a standard windows event loop for processing the messages. But how do I get a window procedure as a target for DispatchMessage without a window?

Standard windows event loop (from MSDN):

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{ 
    if (bRet == -1)
    {
        // handle the error and possibly exit
    }
    else
    {
        TranslateMessage(&msg); 
        DispatchMessage(&msg); 
    }
}

---

Why windows messages? Because they are fast (windows relies on them) and thread-safe. This case is also special as there is no need for the second thread to read any data. It just has to recieve data, write it to the DB and then wait for the next data to arrive. But that's just what the standard event loop does. GetMessage waits for the data, then the data is processed and everything starts again. There's even a defined signal for terminating the thread that is well understood - WM_QUIT.

Other synchronizing constructs block one of the threads every now and then (critical section, semaphore, mutex). As for the events mentioned in the comment - I don't know them.

Answer 1

You don't need a window procedure in your thread unless the thread has actual windows to manage. Once the thread has called Peek/GetMessage(), it already has the same message that a window procedure would receive, and thus can act on it immediately. Dispatching the message is only necessary when actual windows are involved. It is a good idea to dispatch any messages that you do not care about, in case other objects used by your thread have their own windows internally (ActiveX/COM does, for instance). For example:

while( (bRet = GetMessage(&msg, NULL, 0, 0)) != 0 )
{
    if (bRet == -1)
    {
      // handle the error and possibly exit
    }
    else
    {
        switch( msg.message )
        {
            case ...: // process a message
                ...
                break;
            case ...: // process a message
                ...
                break;
            default: // everything else
                TranslateMessage(&msg);
                DispatchMessage(&msg);
                break;
        }
    }
}

Answer 2

It might seem contrary to common sense, but for messages that don't have windows, it's actually better to create a hidden window with your window proc than to manually filter the results of GetMessage() in a message pump.

The fact that you have an HWND means that as long as the right thread has a message pump going, the message is going to get routed somewhere. Consider that many functions, even internal Win32 ones, have their own message pumps (for example MessageBox()). And the code for MessageBox() isn't going to know to invoke your custom code after its GetMessage(), unless there's a window handle and window proc that DispatchMessage() will know about.

By creating a hidden window, you're covered by any message pump running in your thread, even if it isn't written by you.

EDIT: but don't just take my word for it, check these articles from Microsoft's Raymond Chen.

• Thread messages are eaten by modal loops
• Why do messages posted by PostThreadMessage disappear?
• Why isn't there a SendThreadMessage function?

Answer 3

NOTE: Refer this code only when you don't need any sort of UI-related or some COM-related code. Other than such corner cases, this code works correctly: especially good for pure computation-bounded worker thread.

DispathMessage and TranslateMessage are not necessary if the thread is not having a window. So, simply just ignore it. HWND is nothing to do with your scenario. You don't actually need to create any Window at all. Note that that two *Message functions are needed to handle Windows-UI-related message such as WM_KEYDOWN and WM_PAINT.

I also prefer Windows Messages to synchronize and communicate between threads by using PostThreadMessage and GetMessage, or PeekMessage. I wanted to cut and paste from my code, but I'll just briefly sketch the idea.

#define WM_MY_THREAD_MESSAGE_X   (WM_USER + 100)
#define WM_MY_THREAD_MESSAGE_Y   (WM_USER + 100)


// Worker Thread: No Window in this thread
unsigned int CALLBACK WorkerThread(void* data)
{
  // Get the master thread's ID
  DWORD master_tid = ...;
  while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
  { 
    if (bRet == -1)
    {
      // handle the error and possibly exit
    }
    else
    {
      if (msg.message == WM_MY_THREAD_MESSAGE_X)
      {
        // Do your task

        // If you want to response,
        PostThreadMessage(master_tid, WM_MY_THREAD_MESSAGE_X, ... ...);
      }

      //...
      if (msg.message == WM_QUIT)
        break;
    }
  }
  return 0;
}


// In the Master Thread
//
// Spawn the worker thread
CreateThread( ... WorkerThread ... &worker_tid);

// Send message to worker thread
PostThreadMessage(worker_tid, WM_MY_THREAD_MESSAGE_X, ... ...);

// If you want the worker thread to quit
PostQuitMessage(worker_tid);

// If you want to receive message from the worker thread, it's simple
// You just need to write a message handler for WM_MY_THREAD_MESSAGE_X
LRESULT OnMyThreadMessage(WPARAM, LPARAM)
{
  ...
}

I'm a bit afraid that this is what you wanted. But, the code, I think, is very easy to understand. In general, a thread is created without having message queue. But, once Window-message related function is called, then the message queue for the thread is initialized. Please note that again no Window is necessary to post/receive Window messages.