Bringing setTimeout to ECMAScript

David Bruant david.bruant at labri.fr
Sat Mar 19 10:02:27 PDT 2011


Le 19/03/2011 16:39, David Herman a écrit :
>>> It seems to me there are a couple pieces to Mark's concurrency
>>> proposal. One part is formalizing the event queue that already exists.
>> Is this already done in the current proposal? Because I haven't found
>> it.
>
> Sorry, I guess I should say, we can't add concurrency without having
> it be compatible with existing event queue semantics, which likely
> requires formalizing that in Ecma-262.
>
>> Regardless, this work of formalizing the already existing event queue
>> has already been done by the WHATWG:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops
>
> Yeah, I know.
>
>> I think it would be a mistake to start the formalization work from
>> scratch since a decent part of the work has already been done.
>
> Duplicating specs certainly sucks. But it seems nonsensical to me to
> specify things that rely on the event queue without having the event
> queue in the semantics. Maybe the spec would have to cross-reference
> WHATWG? Ugh.
>
> Actually, wait a minute -- I think I disagree with you here. WHATWG
> specifies the specific event queue of the browser. Node.js has its own
> event queue. (...)
Actually, we agree.
I never said that TC39 should copy/paste the event-loop section written
by the WHATWG.
I said that WHATWG has done some on work specifying what currently
happens in browser (joining with your idea of "be[ing] compatible with
existing event queue semantics"). One idea would be to see what they've
done, get inspired and specify the event queue in ECMAScript. Node.js
implementation would be another source of inspiration. But the WHATWG
has written a spec, not an implementation which is subject to change at
anytime. That's the value I was seeing in particularly studying WHATWG
event queue before working on adding event queue to ECMAScript (which,
as you say in your next point is compulsory in a way or another to
define pre-emption-less concurrency).


> I don't think there's any way to specify "run-to-completion" (which is
> really just a hand-wavy way of saying "no pre-emption," which is
> itself really just a way of saying "sequentialized event queues")
> without specifying event queues.
>
> But I still don't see why standardizing timers, and only timers, is so
> important. Node implements them, and they work. What problem are we
> fixing?
>
>> Once, I read the concurrency proposal with in mind "can setTimeout be
>> implemented with what is in this proposal?". I have found the timeout
>> section
>> (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts) and
>> I thought "awesome!"... until I realized that this example is itself
>> using setTimeout (which is consistently implemented in most
>> ECMAScript-based environments but isn't itself part of any ECMAScript
>> version).
>
> Why do you think setTimeout is so special? It seems like just another
> host-environment API like, say, onClick. It provides access to one of
> the host environment's system service.
I agree that it can be considered as an host-environment API.
However, setTimeout seems to be widely implemented. I think it makes
more sense to specify it within ECMAScript. It could be an occasion to
specify what happens when you're in strict mode and you do
setTimeout("alert(this)", 0). Is this string interpreted as strict eval
code? There is a spec hole here. Bringing setTimeout to ECMAScript would
be an occasion to answer the question and not let implementors do
whatever they prefer or even to forget the question. This would avoid
yet another de facto standard.

>> However, the tiny brick/element/component/part that is missing to
>> implement "time event" ("clock event"?) is to take time into account
>> in the proposal.
>
> How is this element's absence any more important than the absence of,
> say, onMouseover? Granted, it has more applicability than just the
> browser (since node.js uses it), but as Kyle's already pointed out,
> some embeddings may not want to expose the system clock.
Actually, a conforming ES5 implementation implements Date.now(). In that
condition, it's hard to not expose the system clock, or am I missing
something?

This is giving me a (terrible) idea to implement setTimeout.
We could have two vats. One asks the second to resolve some promise
after a certain amout of time. The second loops and resolve the promise
when the delay is passed (measured as a delta between Date.now() at
request reception and in the loop test. I warned on the terrible aspect
of the idea). On resolution, the function passed to Q.when in the first
vat is called.
Despite the inelegancy, could it work?


>> And I intuit it wouldn't be that hard to add it.
>
> It's not exactly a walk in the park. Have you ever tried to formalize
> real time? Einstein had a few words to say about this subject.
:-)
I am aware of the theorical problem. However, it has never prevented
people from including "time" in different languages specifications, or
implementing libraries using the concept of "time". There are also
people out there writing "performance benchmarks" where they "measure time"!
Joke aside, there is no need to formalize real time.
For Date.now(), ES5 says:
"The now function return a Number value that is the time value
designating the UTC date and time of the occurrence of the call to now."
About setTimeout and setInterval, WHATWG says:
"This API does not guarantee that timers will fire exactly on schedule.
Delays due to CPU load, other tasks, etc, are to be expected."

In my opinion, these are sufficiently accurate approximations of real
time so that implementors can know what to do while admitting they've
given up on formalizing real time and don't want to dig any further the
topic.


> I still just don't get this whole thread.
> But I still don't see why standardizing timers, and only timers, is so
> important. Node implements them, and they work. What problem are we
> fixing?
So, to summurize a couple of things that has been said:
* With the work on strawman:concurrency, the event loop concept will be
added to ECMAScript.next (regardless what is decided for setTimeout).
* Standardizing setTimeout based on the event loop is basically just
adding a timing component to the event loop.
* "Real time is already in ECMAScript 5 through Date.now()"
* Standardizing setTimeout is the occasion to fully specify the
string-as-a-first argument case to avoid de facto standards before
strict mode or Harmony opt-in is widely deployed.

I was about to say something about security, but since Mark replied, it
will be more acurate to reply to him on the topic.

David


More information about the es-discuss mailing list