Quote:
If it were getting the timer events from the message queue, there would be NO WAY to insure that interval was anywhere near accurate, as you cannot know the execution time of other messages in the queue
No timer can be considered accurate for this very reason. You would have to physically accommodate for every running process on the system and micro manage execution based around timer requirements based on the underlining function execution times in order to make it "accurate" which is realistically impossible to do for unprivileged software /user desktops.
However, the timer would be provided by the OS in order to maintain the highest level of accuracy and, as far as I know this is done via two methods - the main message chain or a dedicate Timer callback function, both of which should class as on the main thread.
A framework implementation would be less accurate and wasteful in resources as the OS will be using hardware level interrupts to provide it's timer mechanism.
DaveS wrote:
you set your timer to interval X
in the Timer Action you call Method ABC
Method ABC takes 3X to complete
the timer WILL fire again even though ABC has not completed..... This will result in ABC NOT completing and starting again
as a matter of fact ABC will NEVER complete as it will be always be interrupted by the timer
This is a situation I have run across numerous times.
The "fix" is easy however.... put a "BUSY" flag at the beginning of ABC... modify the timer event to NOT call ABC if that flag is set. Reset the flag at the end of ABC
Now this is a simplified example,.... because obviiously if that is all the time did, you'd simply expand the interval
But you may have cases where the Timer calls various methods depending on the circumstances.
Timer should not fire again unless the action event of that timer spawns a thread, in which case technically your timer event has returned and a thread is entirely independent of that process. While I don't know the specifics on the OS level implementation, but I'm pretty sure you have to return the message back to the OS too, so the queue will never be filled up with 100s of identical timer events in case execution was prolonged.
if I made a 1ms timer that, lets say opened up a new window and else where I had a function that never returned back to the main loop, that timer event should never fire as it will be blocked - if it did this would imply timers are threaded and RS should be advertising the need to be thread safe (critical sections, etc) but then this is contrary to using them to update the interface instead of using a thread, that single statement alone implies they are on the main thread execution