Bringing setTimeout to ECMAScript

David Bruant david.bruant at labri.fr
Sun Mar 20 04:08:57 PDT 2011


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 mozilla.com> 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 Date.now 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?

David


More information about the es-discuss mailing list