On Thu, Apr 21, 2011 at 11:05 AM, Stephan Beal <[email protected]>wrote:
> On Thu, Apr 21, 2011 at 3:43 AM, MartinWhatever <[email protected]>wrote: > >> i'm currently deciding if i'm going to switch from spidermonkey to V8. >> > > i've used SpiderMonkey extensively, and in my opinion, usages of the > libraries are remarkably similar. e.g. when i started porting my > SpiderMonkey bindings for ncurses and sqlite3 to v8, i found that it was > more or less a 1-to-1 port. Only the callback signatures changes. Since i > use a templates-based framework to convert between C++/JS types, none of > that code code in the bindings had to change (the templates were ported to > use v8 instead). > > >> i really would like to use V8, but if it's not going to be threadsafe >> within a year or so there is absolutely no way that i can use it, and >> that's a shame :( >> > > You can use threads, they just can't in the VM at the same time. A thread > which only needs to run non-v8 code (e.g. making system calls) can unlock > the v8 engine so that other threads can use it. > > >> i simply cannot use it, i don't want users to have to wait for the >> execution of a slow function to complete before the application >> becomes responsive again. >> > > That's JavaScript by design. JS has NO primitives to support threading at > the script level, e.g. mutexes. Even if your engine allows multi-threaded > access, your scripts cannot guaranty proper behaviour in the face of threads > if those threads use any common data. > Let's turn the question around. How in the world does SpiderMonkey support multi-threading? How is it specified? Did they invent a memory-model for JS? > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
