# Multithreading newbie in need of help.

9 replies to this topic

### #1SteveDeFacto

New Member

• Members
• 8 posts

Posted 18 May 2012 - 09:55 AM

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?

### #2alphadog

DevMaster Staff

• Moderators
• 1716 posts

Posted 18 May 2012 - 01:18 PM

How and when do you plan on exiting the loop?

Usually, there's a:
if (Msg.message == WM_QUIT)
break;

in the PeekMessage() block.
Hyperbole is, like, the absolute best, most wonderful thing ever! However, you'd be an idiot to not think dogmatism is always bad.

### #3SteveDeFacto

New Member

• Members
• 8 posts

Posted 18 May 2012 - 02:20 PM

alphadog, on 18 May 2012 - 01:18 PM, said:

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?

### #4}:+()___ (Smile)

Member

• Members
• 169 posts

Posted 18 May 2012 - 02:48 PM

As far as I remember, you must process messages in the thread where you created target window.
Sorry my broken english!

### #5TheNut

Senior Member

• Moderators
• 1699 posts
• LocationThornhill, ON

Posted 18 May 2012 - 03:58 PM

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.
http://www.nutty.ca - Being a nut has its advantages.

### #6alphadog

DevMaster Staff

• Moderators
• 1716 posts

Posted 18 May 2012 - 07:04 PM

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 this and 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.
Hyperbole is, like, the absolute best, most wonderful thing ever! However, you'd be an idiot to not think dogmatism is always bad.

### #7SteveDeFacto

New Member

• Members
• 8 posts

Posted 19 May 2012 - 01:31 AM

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?

### #8TheNut

Senior Member

• Moderators
• 1699 posts
• LocationThornhill, ON

Posted 19 May 2012 - 03:55 AM

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.
http://www.nutty.ca - Being a nut has its advantages.

### #9SteveDeFacto

New Member

• Members
• 8 posts

Posted 19 May 2012 - 08:37 AM

TheNut, on 19 May 2012 - 03:55 AM, said:

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.

### #10TheNut

Senior Member

• Moderators
• 1699 posts
• LocationThornhill, ON

Posted 19 May 2012 - 11:02 AM

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.
http://www.nutty.ca - Being a nut has its advantages.

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users