On Mon, Sep 14, 2009 at 9:15 AM, Erik Corry <[email protected]> wrote:
> "setTimeOut" is an interesting choice for the name of the function. > Browser-based JS environments also have a call with this name, but it > implements something rather different. In the browser there is only > one thread and you have to return from the current JS invocation in > order for new events (mouse clicks, timeouts, etc.) to trigger new JS > invocations. Implementing the setTimeOut function that is known from > browsers would not involve threads. > i wasn't aware that browsers' behaves that way internally. i was aware that long-running (or too many) setTimeout handlers can be problematic, but i wasn't aware that they block for their whole lives. > From the programmers point of view the concurrency model is rather > different. In the browser implementation the functions registered > with setTimeOut can only run when the previous bit of JS code > relinquished control. In JS there is no explicit way to relinquish control, so we're always required to rely on engine-specific definitions of "when is control handed over". AFAIK, in v8 this check is done when functions are called (or only native functions???). Are there other places where v8 checks whether it should give control to another thread? > With your implementation you can potentially > get another JS call running whenever a callback to C++ code occurs. Yes, that's what i was hoping for :). However, i wasn't aware that this was different from what browsers do. Since any use of setTimeout() is, by nature, subject to race conditions and such (since we cannot know exactly when it will run, and JS has no built-in locking/threading mechanisms), i don't expect that my impl is, in terms of use, much different than a browser impl. That is, anyone who uses setTimout() inherently relies on nondeterminstic order of operations, and therefore probably wouldn't notice any functional difference between an MT- or single-threaded setTimeout() implementation unless they're doing questionable operations on objects from both the setTimeout callback and the originating thread. i hope, anyway. On a slightly different note, people on this thread may be interested > in the preemption support that is built into d8. Implementing > something similar in your libv8-using program would allow JS code in > tight loops to be interrupted and other threads to be run even without > explicit flag polling in the JS or callback code. Since there are no > locks or other synchronization primitives available in JS this model > requires separate contexts per thread or a lot of very careful thought > about asynchronous operations at the JS level. > i found the StartPreemption(someNumericType) (or something like that) function, but i'm not at all clear what it does. The API docs say only the obvious: "starts preemption", but doesn't tell us what that really means. Is it to be run once from each thread, once globally, or what? My assumption that it is a global toggle which tells v8 to check ever N millis to see if it should hand control to another thread, but that's just a guess. :) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
