Bringing setTimeout to ECMAScript

Dean Landolt dean at deanlandolt.com
Sun Mar 20 13:30:51 PDT 2011


On Sun, Mar 20, 2011 at 4:05 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 3/20/11 1:55 PM, John J. Barton wrote:
>
>> 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"
>>
>
> _You_ do.  Some sites do that.  A lot of other sites mean "oh, just do it
> the way it looks to me when I test it in this one browser I bothered to test
> with".
>
>
>  I think that is the common meaning.
>>
>
> Both meanings are very common.  If you're claiming that one is more common
> than the other, I'd like to see some data.
>
> In any case, both meanings are common enough that breaking either one
> significantly is not an option.
>
> Again, Chrome tried to make setTimeout(f, 0) run after no more than 1ms,
> and discovered that sites "break" whatever that means.
>
>
>  We assume (without real evidence I suppose)
>>
>
> Yep, definitely without evidence.  ;)
>
>
>  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.
>>
>
> 1)  You would be surprised at what web pages do, re your 3000 thing.
> 2)  "yield" is not good enough if each execution of your timeout takes
>    an appreciable amount of time.  For example, if your execution is
>    10ms but you schedule the timer to run every 2ms, you _will_ swamp
>    the event loop.  84% of the time or so things will be nonresponsive.
>
>
>  The "swamp the event loop" case is logically unrelated to this case,
>>
>
> Not at all.
>
>
>  just like setInterval is unrelated. Multiple repeated calls to
>> |setTimeout(f,0)| are bugs and setInterval of zero would be a bug.
>>
>
> Those are the cases that get clamped.  If you just setTimeout(f, 0) when
> not inside a timeout, you don't get clamped.
>
>
>  Of course the browser has to deal with theses cases, but the lower limit
>> on
>> setTimeout seems like crude solution.
>>
>
> It's the one browser makers have all implemented.
>

The key word here is "browser makers". Maybe node's process.nextTick is a
footgun, but it's one you'll need if you want to roll your own scheduling,
for instance. Apparently there is real evidence that clamping in setTimeout
is necessary but that doesn't mean it makes sense as a language construct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110320/3f99c8b3/attachment.html>


More information about the es-discuss mailing list