

On the nature of timers - sorenbs
http://blog.getify.com/on-the-nature-of-timers/

======
DougMerritt
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.

~~~
_getify
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.

~~~
DougMerritt
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).

~~~
_getify
> 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.

~~~
DougMerritt
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.

I should have said so at the start.

