Bringing setTimeout to ECMAScript

Brendan Eich brendan at mozilla.com
Sat Mar 19 16:15:23 PDT 2011


On Mar 19, 2011, at 7:57 AM, Kyle Simpson wrote:

>>> What I was saying is, if I run this program through V8 right now (with its theoretical future support of setTimeout() included), then what will happen:
>>> 
>>> function fn() {
>>> print("hello");
>>> }
>>> for (var i=0; i<10; i++) {
>>> setTimeout(fn,i*1000);
>>> }
>>> 
>>> That for-loop will finish very quickly (probably <1 ms). Would V8 (or any other JS engine) "finish" in the sense that the calling embedding code thinks this program is completely finished, and it returns back control to the C/C++ embedding layer when:
>>> 
>>> a) right after the for-loop finishes; OR
>>> b) after only the first call to `fn`, since it's timeout was effectively 0, and so would have been immediately after the main program finished; OR
>>> c) after all of the queued up calls to `fn` have finished, about 9 seconds later?
>> 
>> (a) is the right answer because the event loop is run by the embedding, not v8. IMnsHO.
> 
> OK, so what I was asserting in my earlier email is, I'd prefer that if setTimeout() were going to be added to the official language spec, and in fact directly implemented in the engines, that instead of making the embedder's job harder (ie, me), that the engine entirely encapsulate and manage the event loop.

You can encapsulate an event loop within a JS engine, but the API will need to allow for native GUI events, poll on sockets and other files, etc. to be embeddable in a browser or something like nodejs.

This is partly an API discussion, probably off topic for es-discuss. It's just a matter of how big a lump you want to make "on the inside", and how much API that lump needs to meet the demands of its consumers. But you might have to build it yourself.

IOW, this is not the place to demand that a "JS engine" encapsulate an event loop. It's not obviously better for all engines to have OS-specific event loop code, and all the API required (e.g., for X on Linux), than it is to leave that to what ECMA-262 calls "the host environment". But it doesn't really matter here, except that it changes the requirements on embedders.

You're right that standardizing setTimeout would change requirements for embedders of current engines. That's part of the trade-off. No free lunch, but possibly worth it for the core language to grow to include setTimeout.

/be


More information about the es-discuss mailing list