Home/ Questions/Q 4579444
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T20:38:34+00:00

I have a windowless timer (no WM_TIMER) which fires a callback function only once

  • 0

I have a windowless timer (no WM_TIMER) which fires a callback function only once when a given time period is elapsed. It is implemented as a SetTimer()/KillTimer(). Time periods are small enough: 100-300 milliseconds.

Is that cheap enough (I mean performance) to call SetTimer()/KillTimer() pair for every such short time interval?

What if I have 100 such timers which periodically call SetTimer()/KillTimer()? How much Window timer objects may exist simultaneously in the system?

That is the question:
Use a bunch of such timer objects and rely on good Windows implementation of timers, or create one Windows timer object that ticks every, say, 30 milliseconds, and subscribe all custom 100-300 milliseconds one-time timers to it.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem with timer messages as you are trying to use them is that they are low priority messages. Actually they are fake messages. Timers are associated with an underlying kernel timer object – when the message loop detects the kernel timer is signalled it simply marks the current threads message queue with a flag indicating that the next call to GetMessage – WHEN THERE ARE NO OTHER MESSAGES TO PROCESS – should synthesise a WM_TIMER message just in time and return it.

    With potentially lots of timer objects, its not at all obvious that the system will fairly signal timer messages for all the timers equally, and any system load can entirely prevent the generation of WM_TIMER messages for long periods of time.

    If you are in control of the message loop, you could use maintain your own list of timer events (along with GetTickCount timestamps when they should occur) and MSGWaitForMultipleObject – instead of GetMessage to wait for messages. Use the dwTimeout parameter to provide the smallest interval – from now – until the next timer should be signalled. So it will return from waiting for messages each time you have a timer to process.

    And/Or you could use waitable timers – either on a GUI thread with MSGWaitForMultipleObjects, or just on a worker thread, to access the lower level timing functionality directly.

    • 0