Bringing setTimeout to ECMAScript

[Brendan Eich]

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