On Wed, Sep 16, 2009 at 5:23 PM, SteveC <[email protected]> wrote:
> Now, I expect this is naive of me, but I notice there is lots of > static data in the codebase. if I were to refactor this into some kind > of 'GlobalContext' class, could I not simply instantiate multiple of > those GlobalContexts without them interfering with each other? > One of the major diffs between v8 and, e.g., SpiderMonkey is that none of the v8 API takes a Context/Engine argument. In SpiderMonkey, nearly every function takes a Context argument (as it should, IMO). v8's usage of static data instead of an explicit argument inherently limits it in regards to threading/concurrent access. While v8 could, in theory, be a widely-applicable engine, it was designed with the sole purpose of supporting Chrome. The API limitations which that decision have led to will always limit v8 severely in terms of concurrency and re-use. e.g., the main reason which v8 does not call GC at engine shutdown is because doing so slows down the shutdown of Chrome, as one v8 developer admited on the list some months ago. That Chrome-induced limitation bleeds over into my apps, however, and number of the types i wrap (e.g. DB handles) require that their dtors get called at some point, and v8 cannot guaranty that for me. OTOH: there has never been, AFAIK, a working SWIG wrapper generator for JavaScript. As far as i've been able to determine (by exploring SWIG), this is because the Context/Engine argument required by the JS API makes it nearly impossible to bind in to the SWIG system (which doesn't want to know about that Context/Engine). Since v8 doesn't have this argument, i expect that someone will be able to create SWIG wrapper generator for v8. > Or is there funky stuff to do with thread local storage or something else > that would make this fail? Thread-local storage could probably be used to "solve" (at least partially) this "problem" (assuming TLS is available on all platforms Chrome wants to run on), but that would also make it more difficult (i believe) for more than one thread to interact with the same VM (because each thread would see its thread-local Context, rather than the global one). IMO, the API should be completely rewritten, inserting a Context argument as the first argument to nearly every function (that is, anywhere a Context is internally needed and cannot be extracted from another argument). But the project is now too big for such a change. The "global everything" aspects of v8 will, over time, probably turn out to be the biggest hindrance to its adoption. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
