Kyle;
On Fri, Mar 18, 2011 at 11:53 PM, Kyle Simpson <get...@gmail.com> wrote:
> Speaking as someone who has written and currently maintains a *synchronous*
>>> server-side JavaScript environment (based on V8),
>>
>>
I resemble this description, except that my platform is built on
SpiderMonkey rather than V8. That said, I do not share your concerns with
respect to the introduction of setTimeout.
You've laid out a number of implementation scenarios, but I believe they are
properly addressed by the embedding API for your JS engine. Basically, the
JS engine can do one of two things:
1) not return until there are no more pending events
2) return immediately, and let the embedder know that there is still code
waiting to be serviced, and to provide some kind of servicing API.
#1 is an unlikely implementation, as it would not play nicely with the
browser, and, frankly, makes for a lousy API. In the strange case where
this happens and the program needs to terminate immediately without concern
for pending events, you would have to add some kind of mechanism in your
platform that causes you to bail immediately.
One approach I have implemented in my own work is to throw a Number rather
than an Error; e.g. throw 3 behaves a lot like exit(3) in C.
#2 is far more likely and gives you total control. Either you can ignore
pending events, or you can wait to service them. #2 not only plays well
with the browser, but would be very easy to integrate with something like
libev if you wanted to implement a platform like Node.js. I would be
tickled pink if something like this appeared in SpiderMonkey.
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 my #2, and I believe the right solution -- but I stress that this is
an engine question and not a spec question.
b) should never happen, and anyhow, it's a special case of either a or c.
c) is my #1, and I believe is not a solution any browser-vendor's engine
would implement....unless the JS engine's event loop also ran the browser,
which strikes me as a backwards design.
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.
If V8 implements something like #2, they will need to include some kind of
an API letting the embedder (you) know about pending events so that you can
run them.
Like I said, I don't see this being an issue for our use-cases, provided the
engine implementors continue to make good decisions.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
