On Mar 18, 2011, at 9:25 AM, Wes Garland wrote: > Right: the barrier to setTimeout functionality is that ECMAscript does not > define a concurrency model. > > If we can define a concurrency model, then we can build setTimeout.
See my previous reply. JS with setTimeout has only pseudo-concurrency via time-deferred script executions or function calls. There's nothing concurrent in a racy sense there. > Two things off the top of my head to consider: > - timer granularity This is an interop issue, mostly due to stupid benchmarks that degenerate to measuring whether the browser clamps at 10ms or 4ms. It is also now a standard: 4ms. Various implementors have found that setTimeout(f, 0) that calls f immediately "breaks the web" (or at least the New York Times site). Similarly, waiting an event loop turn seems to break the web. By testing, 4ms has been arrived at. I welcome fresher data. > - forbidding eval-like syntax What problem are you solving? > OTOH, if we have an event-loop system with conditionals, we might not need > setTimeout because it would be trivial to build from primitives. But it might > be a handy interface if ES starts to go toward the "batteries included" model. What do you mean by conditionals? If you mean condition variables, JS will never grow to include shared-mutable-state threads. That would happen not only over my dead body, but the rest of TC39's. We'd fight back, so watch out. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
