Bringing setTimeout to ECMAScript

Jorge Chamorro jorge at
Sun Mar 20 06:33:02 PDT 2011

On 20/03/2011, at 13:51, Jorge wrote:
> On 20/03/2011, at 12:08, David Bruant wrote:
>> Le 20/03/2011 04:11, Brendan Eich a écrit :
>>> On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
>>>> On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich <brendan at> wrote:
>>>>> setTimeout does not introduce threads, shared memory among them, or even
>>>>> non-determinism if we spec carefully (browsers have to implement carefully
>>>>> already).
>>>> `setTimeout' already introduces nondeterminism based on the speed of
>>>> the implementation.  Consider:
>>>> setTimeout(f1,1000)
>>>> compute()
>>>> setTimeout(f2,0)
>>>> If `compute' takes a long time, then `f1' runs before `f2', otherwise
>>>> `f2' runs first.
>>> Isn't the non-determinism entirely in compute(), so that if you replace the two setTimeout calls with calls, saving results, you can measure the ND that either does or does not reorder f1 with respect to f2?
>>> My point was that setTimeout, unlike threads racing over shared mutable state, does not introduce new sources of ND not already in the current execution model.
>>> We need to be careful about order, though. If setTimeout(f1, 1000) schedules f1 to be called at t1, and setTimeout(f2, 0) schedules f2 at t2, then if t2 >= t1, f1 should be called first. I'm not sure all browsers implement this.
>> I'm sorry, but even though I agree on the principle, I do not know why
>> "f1 /should/ be called first".
>> With names:
>> ----
>> setTimeout(f1, delay1);
>> computea();
>> setTimeout(f2, delay2);
>> computeb(); // to enforce the idea that the program doesn't stop right away
>> ----
>> At the end, f1 is scheduled at t1, f2 at t2. (t1<t and t2<t with t
>> present time). We have two timeouts ready to be fired, there is a
>> decision that has to be made on the firing order. I would personnally
>> choose yours, which is to call the function that has been the most
>> delayed (max(t - t_i)). However, other decision policies could be valid.
>> For instance, choosing max( (t-t_i)/delay_i ) could be a valid policy
>> too. The rationale would be to keep at a minimum not the absolute delay,
>> but the relative delay.
>> Another thing that could be taken into account is heuristics on the time
>> that f1 and f2 take to execute.
>> Mixing all these things together, there are certainly other valid
>> policies that could be considered.
>> Once again, my personal preference, the policy I find the most fair, is
>> reducing absolute delay as you suggest, but is there a reason why this
>> /should/ be the behavior accross browsers? Should even the behavior be
>> consistent across browser? Across hardware, ES engine implementation and
>> external factors (OS scheduling with other programs), computea and
>> computeb can make t1 and t2 relative order different from one run to
>> another. So there is no way to test the consistency.
>> Is there a reason why you're expecting browsers 1) to be consistent in
>> their policies 2) to choose a particular policy?
> A timer that expires is an event, and I would expect events to be serviced in the order they happen. As when I click twice, I'd expect the first click to be serviced before the second click.
> So given 2 timers, expiring at t0 and t1 with t0 < t1, if is >= t0 and >= t1, I would expect t0 to be serviced first, yes.

And if t0 were === t1, I would also expect them to be serviced in the same order in which they were setup:

setTimeout( f1, 0 );
setTimeout( f2, 0 );
setTimeout( f3, 0 );
setTimeout( f4, 0 );
setTimeout( f5, 0 );



More information about the es-discuss mailing list