Bringing setTimeout to ECMAScript

Brendan Eich brendan at mozilla.com
Fri Mar 18 22:29:16 PDT 2011


On Mar 18, 2011, at 8:53 PM, 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.


> In other words, to put it simply, if program A can call setTimeout(), and I want to run program A and then program B, I have to be able to make sure that I don't try to run program B until everything is fully finished in A. As V8 stands now, there's no way to do anything non-synchronous, so when A finishes, I know it's totally finished. I'm concerned that there'd be some new way with setTimeout()'s that this wouldn't be true.

This is not true today with V8 in Chrome, precisely due to setTimeout!

It's not true in Node either.

I'm not sure where you think it's true. V8 embedding in something without setTimeout or anything like it, sure. But then you can't write simple time-based programs, set alarms, etc., so back in the door comes setTimeout or a workalike...

/be


More information about the es-discuss mailing list