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.
jjb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
