a storm of timers ☠️

[Łukasz997 117]

Some time ago, in a thread about abnormally high CPU load on the HC3, it was mentioned a problem with recurring setTimeout - i.e., starting a new timer before the previously scheduled one fires. In a complex script, it’s easy to make this logical mistake. It can snowball and is quite hard to debug. While experimenting with OOP (which I’m a bit afraid of, because I’m not very fluent in it), I came up with an idea to workaround for this problem: "auto-cancelling" timers. Here’s an example:

Please login or register to see this code.

Timer:new() constructs instance of improved timer, method "after" is identical to hub.setTimeout, but it incorporates auto-cancel feature.

The first timer (5000 ms) will never fire - because before it does, another timer (7000 ms) is scheduled, which cancels the previous one. Now the user no longer has to remember to cancel the previous timer. Though, to be honest, it’s still better to keep that in mind… If you need multiple timers, just create multiple Timer objects - the auto-cancel behaviour applies per instance.

Hope that’s useful.

 

Edited August 16, 2025 by Łukasz997