Bringing setTimeout to ECMAScript
bzbarsky at MIT.EDU
Sun Mar 20 10:07:28 PDT 2011
On 3/19/11 5:29 PM, Jorge wrote:
> I have always wondered about the reason to clamp (nested) setTImeout()s, why, what for ?
Originally, implementations effectively clamped setTimeout because the
timer primitives they were using only had about 10ms resolution (due to
being based on the context-switching frequency of the OS, which was
100Hz for at least Windows and Linux at the time; not sure about others).
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean "run this at 10Hz" and if you run it with no delay then
they swamp your event loop and possible render "wrong" (e.g. the text
disappears before the user has a chance to read it).
At least that's what I understand; you may want to ask the Chrome folks
what issues they ran into when using a 1ms clamp.
Using no clamp at all _will_ swamp the event loop in common cases used
on the web and doesn't seem desirable.
> Is it to protect the users' mobiles/laptops batteries from event loops spinning unnecessarily fast in some badly written web pages
Not just batteries. Also the UI in browsers that don't have separate
threads for content and the UI.
Note that as far as batteries go at least IE9 seems to use a different
clamp when running on battery. This probably has to do with the fact
that getting timers with resolution better than 10ms on Windows involves
changing the scheduler's timeslice in a way that consumes more power
even if you aren't running timers all the time.
> or perhaps in some popular (and possibly botched) library ?
0ms timeouts are all over the place on the web. They're in libraries,
they're in websites. They're everywhere.
> And if that's the reason, and if the clamp is needed/wanted/kept for that reason, what are we going to do to protect against functions that nextTick() themselves ?
Accidental misuse is a lot less likely if there is never a clamp in
place. In particular, the "text disappears too fast" scenario can't
arise in this situation. And I expect that web-facing UAs will
introduce additional clamps as needed to deal with resource constraints
(e.g. what IE9 is doing on battery).
> And if we can't protect against nested nextTick()s, then, does it make sense to keep the protection against setTimeout()s of 0 ?
It does in web-facing UAs, due to the huge mass of existing
More information about the es-discuss