You may be able to improve the timers a bit one way or another, but in general most of those issues are not wholly fixable without moving to a real time operating system.
For instance, on a non-RTOS scheduler, although usually things happen fairly soon after expected, there can be an unbounded delay, which in some reasonable models approximates a Gaussian with an indefinitely long tail.
None of that is under the control of applications/libraries running on the OS.
Not that an RTOS magically fixes everything, due to things like implicitly conflicting goals.
But the article is not about the precision of timers happening at exact moments. It's about the nature of their relative timings. I don't see why the OS would need to be involved in the latter.
If the threads and their scheduling are implemented wholly by the language, not the OS, then perhaps the ordering of their wake-ups could be guaranteed -- although I'm not sure these languages do guarantee it.
Maybe they had some reason for using a LIFO instead of a FIFO, who knows; one needs to check these things.
However, the thing that triggered me to comment was this part:
> If it runs significantly after 953ms, that’s OK, but there probably needed to be a good reason, like the entire thread being blocked unexpectedly.
This is simply mistaken, in strongly implying that it takes unusual conditions for events to lag significantly; actually that is just normal functioning, and does not need "unexpected blocking" or anything else unusual or rare to occur.
It is ameliorated a lot by avoiding heavy loading of systems (that doesn't fix it, but it can reduce strange behavior down to a statistically tolerable level).
> If the threads and their scheduling are implemented wholly by the language
There's just one thread, one event loop, for all of JavaScript... so we're not talking about true thread-level race conditions.
> strongly implying that it takes unusual conditions for events to lag significantly
As far as expectations of software running inside of web pages, it is in fact quite exceptional for there to be significant delays between when you expect for something to happen and when it actually happens.
For example, if I set up a timer for 953ms from now, and it actually runs at 3953ms from now, that extra 3 seconds is extremely uncommon for the UX expected on the web.
I think the disconnect here is that you're really asserting things about what happens at the OS level, where multiple threads and real I/O are happening, etc.
I'm entirely talking about JavaScript, which is single-threaded, and where asynchrony is just simple event-loop concurrency (interleaving actions). It means that two timers should, in simplest terms, order themselves according to normal expectations. It'd be unusual for there to be significant deviations.
Ok, so long as you know all these things to be true of JavaScript, and to be guaranteed in the future also, then well and good.
I thought it was merely hope, which set off my internal alarm bells.
Because of that yellow alert, I neglected to say before: I love projects like this, and I really like what you're aiming at. Also there's something about timers in particular that I think makes them cool.
For instance, on a non-RTOS scheduler, although usually things happen fairly soon after expected, there can be an unbounded delay, which in some reasonable models approximates a Gaussian with an indefinitely long tail.
None of that is under the control of applications/libraries running on the OS.
Not that an RTOS magically fixes everything, due to things like implicitly conflicting goals.