Bringing setTimeout to ECMAScript
Brendan Eich
brendan at mozilla.com
Fri Mar 18 16:26:14 PDT 2011
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
More information about the es-discuss
mailing list