Bringing setTimeout to ECMAScript

[Boris Zbarsky]

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 
poorly-authored content.

-Boris