Multithreading newbie in need of help.

Ee4b169a069ef358df51a571abc035cf
0
SteveDeFacto 101 May 18, 2012 at 09:55

So I decided to try my hand at multi threading today. I thought making a thread to handle window messages would be a simple place to start. However, the window is unresponsive when I try this. Here is the function I am using for my thread:

void DoEvents(void *params)
{
Window* window = (Window*)params;
MSG msg = {0};
while( 1 )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
}
}

So why would this not work?

9 Replies

Please log in or register to post a reply.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 May 18, 2012 at 13:18

How and when do you plan on exiting the loop?

Usually, there’s a:

if (Msg.message == WM_QUIT)
    break;

in the PeekMessage() block.

Ee4b169a069ef358df51a571abc035cf
0
SteveDeFacto 101 May 18, 2012 at 14:20

@alphadog

How and when do you plan on exiting the loop?

Usually, there’s a:

if (Msg.message == WM_QUIT)
    break;

in the PeekMessage() block.

I planed on using my IDE to break the loop. Any idea why the window is not processing messages?

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 May 18, 2012 at 14:48

As far as I remember, you must process messages in the thread where you created target window.

6837d514b487de395be51432d9cdd078
0
TheNut 179 May 18, 2012 at 15:58

Indeed you shouldn’t separate the message loop from the thread that created your window. All windowing systems I know of adhere to that requirement, including OpenGL contexts. I’ve never had the need to offload the message loop to a separate thread. I keep the message loop in the main application thread and create additional threads as needed when I want to execute logic separate from the main (aka UI) thread.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 May 18, 2012 at 19:04

I realize I did not answer the root question and others did. As has been said by Smile and TheNut, Windows sends messages to the thread that created the window. For additional info, I refer you to thisand this. Of course, there are ways to beat the system into submission, but it is usually so much overhead that it isn’t worth it.

Ee4b169a069ef358df51a571abc035cf
0
SteveDeFacto 101 May 19, 2012 at 01:31

I want to have my library process messages and not have to have the user call a command to do it every frame. What would be the best way to do that? AttachThreadInput? Or is there a way I can do it with the main thread?

6837d514b487de395be51432d9cdd078
0
TheNut 179 May 19, 2012 at 03:55

Make your library static, add your WinMain function and your win32 message callback function in your library, as well as your message pump. When you link your library into your main project and run it, the compiler will link your win32 entry point and execute the window logic as you defined. The main app doesn’t need to concern itself with any window logic. Just add some events and other helpful methods in your library so you can override or extend the message loop. For example, in your message pump after you peeked at all messages, dispatch a “render” event. The main app can listen for this and draw a frame or do whatever.

Ee4b169a069ef358df51a571abc035cf
0
SteveDeFacto 101 May 19, 2012 at 08:37

@TheNut

Make your library static, add your WinMain function and your win32 message callback function in your library, as well as your message pump. When you link your library into your main project and run it, the compiler will link your win32 entry point and execute the window logic as you defined. The main app doesn’t need to concern itself with any window logic. Just add some events and other helpful methods in your library so you can override or extend the message loop. For example, in your message pump after you peeked at all messages, dispatch a “render” event. The main app can listen for this and draw a frame or do whatever.

I kinda wanted to be able to compile the library as a DLL.

6837d514b487de395be51432d9cdd078
0
TheNut 179 May 19, 2012 at 11:02

That’s fine. You’ll just have to include the WinMain function in your main app instead of your library because you can’t have the main entry point in a DLL. The static library would allow you to fully encapsulate the Win32 system so your main projects can use a standard startup routine rather then deal with window creation and setting up the message pump. This would be beneficial if you wanted to write portable code that uses different window systems. You can still have your library process the win32 messages, just have your main app call the necessary class or function to startup the loop.