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 <bren...@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?
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 Date.now() is >= t0 and >= t1, I would expect t0 to be serviced first, yes. -- Jorge. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
