Bringing setTimeout to ECMAScript
John J. Barton
johnjbarton at johnjbarton.com
Sun Mar 20 10:55:16 PDT 2011
On 11:59 AM, Boris Zbarsky wrote:
> 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).
I'm not convinced that this is the meaning. I use |setTimeout(f, 0)| to
mean "schedule f after this event completes" or "push |f| onto the event
queue"; I think that is the common meaning. A delay value of zero is
perfectly sensible, but we mean "zero seconds after other queued
events", not "zero seconds after this event". We assume (without real
evidence I suppose) that UI and IO events can be queued while our JS
(the caller of |setTimeout(f, 0)|) runs.
The essential logic of |setTimeout(f, 0)| is cooperative multiprocessing
yield: we believe that our current event processing could be long enough
to interfere with user interaction and |f| can be delayed without
serious impact on the UI. We have no reason to pick a value other than
zero. If we want to give the user 3 seconds to read text we use 3000.
The "swamp the event loop" case is logically unrelated to this case,
just like setInterval is unrelated. Multiple repeated calls to
|setTimeout(f,0)| are bugs and setInterval of zero would be a bug. Of
course the browser has to deal with theses cases, but the lower limit
on setTimeout seems like crude solution.
More information about the es-discuss