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