Question

I spent some time trying to research a definitive answer for this and couldn’t find a reliable source.

My scenario is fairly straightforward. I have a thread with a message pump setup that is processing a recurring event from a timer. Here is the message pump source:

// create timer that goes off every 500 ms
UINT_PTR myTimerID = SetTimer(NULL, 0, 500, TimerCallback);

// message structure
MSG msg;

// process and handle messages for this thread
BOOL getMessageStatus;
while((getMessageStatus = GetMessage(&msg, NULL, 0, 0)) != 0)
{
    // failed get message
    if(getMessageStatus == -1)
    {
        printf("GetMessage FAILED!\n");
    }
    // process timer message
    else if(msg.message == WM_TIMER)
    {
        // invoke callback
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}

If TimerCallback takes longer than 500 ms, the timer will have fired its event again. Since, the callback is being executed on the same thread as the message pump, I assume that the callback must complete before the next timer message is processed by the message pump.

Is that correct?

Answer 1

SetTimer() is a message-based timer. When the timer elapses, it sets a special flag inside the message queue. When you pump the queue for new messages, a WM_TIMER message will be created if that flag has been set and other higher-priority messages are not waiting in the queue. While your code is busy dispatching a generated WM_TIMER message, the timer can elapse in the background and set the flag again, generating a new WM_TIMER message the next time you pump the queue for messages. So be careful about pumping messages while inside the callback, either directly or via modal dialogs, as that can potentially lead to recursive calls of your timer callback and thus may cause a stack overflow over time. But if your message pumping is only in your main thread loop then you will be fine.