On Wed, Apr 7, 2010 at 10:44 AM, Matthias Ernst <[email protected]> wrote:
> I think you need to specify better what semantics you intend. What is that > "main" thread? Traditionally, in JS there is no main(), > The main thread is, in this context, whatever thread called setTimeout() in the first place. In the case of nested setTimeouts(), it need not be the "real" main thread. > no piece of JS ever runs continuously or gets interrupted. Even the > "initially" executing script needs to terminate before a setTimeout script > will run. > That's not my understanding of what's been posted on this topic before. As i understand it, at certain points the v8 engine checks for interruption (e.g. for a chance to gc) and can switch threads at those points. Or is that not so? v8 allows any number of threads, but only 1 may access v8 at a given time. e.g. if i use an Unlocker, i am explicitly giving v8 a chance to continue running OTHER JS code/threads while i continue to do whatever it is i do in my thread (but i may not use the v8 API while i'm in Unlocker mode). e.g. for my sqlite3 binding i Unlocker before calling the sqlite3 API, to avoid hanging v8 while a long query runs. Likewise, in my sleep() binding i Unlock for the duration of the sleep() call. > Once you realize that, you only ever need one thread that executes the > event handlers / timeouts and "setTimeout" just needs to push them onto some > priority queue. > i'm not thread-savvy enough to figure out how to get the setTimeout() job back into my main thread, otherwise i would have re-implemented it that way already :/. > Add to that I/O events and you've arrived at node.js (http://nodejs.org) > Doh - i will definitely take a close look at your setTimeout() implementation :). Thanks for the link. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users To unsubscribe, reply using "remove me" as the subject.
