Is there a difference between using `PostQuitMessage` and just processing all messages? - c

Question

I wonder whether there's a difference between those two snippets:
One:
void main()
{
// ...
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
ExitProcess(0);
}
// ...
void quit()
{
PostQuitMessage(0);
}
Two:
bool quit = false;
void main()
{
// ...
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
if(quit)
{
while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&_msg);
}
ExitProcess(0);
}
}
// Shouldn't get here
ExitProcess(1);
}
// ...
void quit()
{
quit = true;
PostThreadMessage(GetCurrentThreadId(), WM_NULL, 0, 0);
}
Sorry but I couldn't come up with shorter snippets.
The point of my question is whether calling PostQuitMessage and processing all messages with GetMessage is equivalent to processing all messages with PeekMessage, until it returns FALSE.
According to Raymond, WM_QUIT is "generated only when the message queue is otherwise empty", so it looks like the two methods should do the same, but perhaps there's a subtle difference.

Answer 1

Raymond's blog post says:
Because the system tries not to inject a WM_QUIT message at a "bad
time"; instead it waits for things to "settle down" before generating
the WM_QUIT message, thereby reducing the chances that the program
might be in the middle of a multi-step procedure triggered by a
sequence of posted messages.
So in theory no, there is no difference, because the system won't generate WM_QUIT until the queue is empty. However Raymond doesn't say that it's guaranteed that messages won't arrive after WM_QUIT is generated, only that the system tries to avoid it.
Therefore it's conceivably possible that another thread could post you a message after you've exited your main GetMessage loop, and depending on your application this may be something you have to deal with. For example, if you post messages internally with memory allocations that the receiving thread is expected to free, you may need a separate PeekMessage loop to clean them up before the thread exits completely.
In practice however no one ever writes message loops like your second example.

Answer 2

I don't think the accepted answer addresses the real issue.
Raymond answers this question directly here.
Basically:
You do not have control over every message loop, so you don't have that option.
Oh, and by the way, don't forget to PostQuitMessage inside your own message loops.
Note that even WTL neglects to do this!
It relies on you passing the return value of CMessageLoop::Run to PostQuitMessage.