Windows: two threads handling messages? - c

Question

I want to have two threads to handle windows messages. One for key/mouse input in the client area (this thread also takes care of game logic) and one for the rest because I am making a game and some messages cause DefWindowProc() to block (thus freezing the game).
How can I achieve this?

Answer 1

Contrary to what Cody wrote, you most definitely can process messages from multiple threads. However, this is not a customizable free-for-all. Rather, windows have thread affinity: each thread will receive the messages sent or posted to windows created by that thread. There's no way to have any window's messages delivered to any other thread.
For your particular situation, why not create a worker thread with its own hidden window and message loop? Any time the main window receives a message you don't want to process in the main thread, post it to the other window, it will be queued to and processed by the worker thread.

Answer 2

You should only need a single thread handling the message queue, which is what Windows already supplies. If you are doing anything which is computationally heavy, you should dispatch it off to a separate thread by creating a new one with CreateThread. If you find you are constantly doing this, then have that thread permanently there but signal it to do work when you need to.

Answer 3

No, all messages need to be processed on a single thread. This single thread is often called the UI thread because it is the one that controls the user interface. Trying to process UI messages on a non-UI thread will just get you into trouble.
However, a common problem is applications that perform long-running, computationally-intensive tasks in response to particular messages. This doesn't work out well because while the code is running inside of the message handler, the application is unable to process other messages (threads can only do one thing at a time), and your UI becomes unresponsive.
The solution is to spin off another thread (or two or however many you need) and delegate the long-running, computationally-intensive tasks off to that thread. You'll still handle the messages on the single UI thread, but inside of the message handlers is where you'll pass off the task to the helper threads. You'll frequently hear this referred to as the "worker thread" or "background thread" pattern.
You can create additional threads using the CreateThread function. You can find a sample here.
In this case, it sounds like the QueueUserWorkItem function might be a simpler option. Sample code:
DWORD CALLBACK ThreadProc(LPVOID p)
{
HWND hWnd = reinterpret_cast<HWND>(p);
for (int i = 0; i < 100000; ++i)
{
// do whatever
}
return 0;
}
LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_KEYDOWN: // or whatever message you want to respond to
{
QueueUserWorkItem(ThreadProc, hWnd, WT_EXECUTELONGFUNCTION);
return 0;
}
// process other messages...
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
Required reading on Win32 thread pools is here.