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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
