Hey all, I've heard it said that ideally a Win32 app's message pump should be placed in a separate thread. However, from my point of view this would create far more problems than it would solve.
-You would have to create/initialize the window from the worker thread: more work for you.
-You would have to worry about thread synchronization whenever responding to events such as a button click, repaint, keyboard, etc.: more headache for you.
-You would have to worry about init and cleanup of a thread, rather than just terminating the message loop and quitting: more work for you.
-Unless you thread sync, virtually nothing can be done in the original thread; But if the GUI thread is waiting on a sync object while your main thread does something slowly, you've just lost any potential benefit.
-You can reproduce much the same effect by placing mini-messagepumps in your functions that block.
The only advantage I can think of, is in the event of you wanting to use GetMessage() and another non-user-defined blocking function at the same time; but few functions (Winsock excluded) will block for a noticeable amount of time, and if polling/asynchronous is an option (like in Winsock) then you can switch to "PeekMessage(), then poll other", with a Sleep(1); thrown in there to prevent eating all the CPU time.
Can anyone give me a better, solid example of why you'd want to separate your message loop from your main thread?
Thanks.
