Bringing setTimeout to ECMAScript

Kyle Simpson getify at gmail.com
Sat Mar 19 07:57:36 PDT 2011


>> 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.

I realize I'm certainly in the vast minority with that opinion, but I'm 
simply saying that not everyone who embeds JavaScript deals with life in an 
asynchronous/isosynchronous mindset. We're not all clones of Node.js. My 
embedding is entirely synchronous, and always will be, for its use case. 
Which means that if we introduce asynchronicity/isosynchronicity at some 
level, like in the actual JavaScript layer (with setTimeout(), etc), then at 
some higher level, like the engine (my preference), or my embedding (not my 
preference), "blocking" behavior has to be written so that I can maintain 
the external synchronicity that my embedding provides. Namely, I have to be 
able to ensure that program A is totally done before program B runs.

Could I figure out event-loop semantics in my C/C++ layer, assuming the V8 
API exposed some API way to determine if events were still unfulfilled, and 
basically provide the event-loop functionality *per-program* in my 
embedding? Sure, I guess I could always learn how to code that stuff. Or, I 
could simply go to extra work to disable any such native functions so that 
code running through my embedding cannot create isosynchronous conditions.

Neither of those two are very preferable scenarios to me. What I like about 
my embedding of V8 right now is, I don't have to worry about those details, 
so my embedding is straight-forward and simple.


>> 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...

If I embed V8 in a simple C/C++ program, and I try to run a snippet of 
JavaScript that calls `setTimeout(...)`, the V8 engine complains and says 
that setTimeout is undefined. Ergo, my assertion that setTimeout() is *not* 
in core V8, but must be added to V8 by the Chrome/Chromium embedding.

As I said above, I don't currently go to that extra trouble, because for my 
embedding use-case, such functionality is more trouble than it's worth.

What I'd simply prefer not to be forced into is some day the core engine (by 
virtue of the core JS spec requiring it) of something like V8 having 
setTimeout() defined, and *forcing* the embedding to have to deal with the 
event-loop. Not everyone who does JS embedding needs such constructs.

Perhaps my complaint is more an engine/embedding complaint than a JS spec 
complaint. Perhaps what I'm saying is, I'd want for there to be an easy way 
for embedding with V8 (or any other engine) to be able to turn off/disable 
isosynchronous APIs so that the embedding wasn't forced to deal with the 
event-loop.

--Kyle
 



More information about the es-discuss mailing list