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? David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
