v8 - Can v8 Engine Run different javascript in multi-thread in the same time?
2,873 views
Skip to first unread message
TengAttack
Apr 19, 2011, 12:25:27 AM4/19/11
to v8-users
Hello, Can v8 Engine Run different javascript in multi-thread in the
same time?
I got the infomation from internet, they said it should v8::Locker,
but I don't want to use it.
How should I do?
same time?
I got the infomation from internet, they said it should v8::Locker,
but I don't want to use it.
How should I do?
Stephan Beal
Apr 19, 2011, 2:53:35 AM4/19/11
to v8-u...@googlegroups.com
You have to use Locker. v8 cannot run JS in multiple threads at the same time. Client code must use Locker to synchronize the threads.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
Matt Seegmiller
Apr 19, 2011, 2:54:06 PM4/19/11
to v8-u...@googlegroups.com
What about using Isolates? If I understand them correctly, they allow for
multiple instances of V8 running from different threads interacting with
different contexts and JS objects at the same time. For anyone working on
them, is that correct? And are they ready to be used? Last time I looked
into them (> 6 months ago) they were still in an experimental state, but
recently when I updated to a 3.x version of V8 I had a crash when looking
for a default Isolate that wasn't there (turned out I was trying to clean up
V8 objects from a thread different than what allocated them). So I got the
impression that maybe they can be used now.
matt
multiple instances of V8 running from different threads interacting with
different contexts and JS objects at the same time. For anyone working on
them, is that correct? And are they ready to be used? Last time I looked
into them (> 6 months ago) they were still in an experimental state, but
recently when I updated to a 3.x version of V8 I had a crash when looking
for a default Isolate that wasn't there (turned out I was trying to clean up
V8 objects from a thread different than what allocated them). So I got the
impression that maybe they can be used now.
matt
joko suwito
Apr 19, 2011, 8:47:06 PM4/19/11
to v8-u...@googlegroups.com, jok...@gmail.com
join with googlegroups. thank you
MartinWhatever
Apr 20, 2011, 9:43:59 PM4/20/11
to v8-users
i'm currently deciding if i'm going to switch from spidermonkey to V8.
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 :(
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.
and, i cannot create a separate context for these slow functions, + i
don't want the user of my program (the person writing the scripts) to
even know about threads, limitations etc...
please PLEASE ! make it thread safe, at least as an option, i'm ready
to wait 18 months for it.
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 :(
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.
and, i cannot create a separate context for these slow functions, + i
don't want the user of my program (the person writing the scripts) to
even know about threads, limitations etc...
please PLEASE ! make it thread safe, at least as an option, i'm ready
to wait 18 months for it.
Stephan Beal
Apr 21, 2011, 5:05:12 AM4/21/11
to v8-u...@googlegroups.com
On Thu, Apr 21, 2011 at 3:43 AM, MartinWhatever <mart...@gmail.com> 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.
Matthias Ernst
Apr 21, 2011, 6:58:22 AM4/21/11
to v8-u...@googlegroups.com
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
Apr 21, 2011, 7:41:23 AM4/21/11
to v8-u...@googlegroups.com
On Thu, Apr 21, 2011 at 12:58 PM, Matthias Ernst <matt...@mernst.org> wrote:
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?
They have some magical macro called JS_THREADSAFE which, when set, enables threading support.
The SpiderMonkey readme says:
----------
<a NAME="Build"></a>Build conventions (standalone JS engine and shell)
(OUT OF DATE!)</h2>
These build directions refer only to building the standalone JavaScript
engine and shell. To build within the browser, refer to the <a
href="http://www.mozilla.org/build/">build
directions</a> on the mozilla.org website.
<p>By default, all platforms build a version of the JS engine that is <i>not</i>
threadsafe. If you require thread-safety, you must also populate
the <tt>mozilla/dist</tt> directory with <a href="http://www.mozilla.org/projects/nspr/reference/html/"
>NSPR</a>
headers and libraries. (NSPR implements a portable threading library,
among other things. The source is downloadable via <a href="http://www.mozilla.org/cvs.html">CVS</a>
from <tt><a href="http://lxr.mozilla.org/mozilla/source/nsprpub">mozilla/nsprpub</a></tt>.)
Next, you must define <tt>JS_THREADSAFE</tt> when building the JS engine,
either on the command-line (gmake/nmake) or in a universal header file.
----------
Specific functions mention specific serialization requirements when JS_THREADSAFE is set, but beyond that it's anyone's guess.
Matthias Ernst
Apr 21, 2011, 11:42:40 AM4/21/11
to v8-u...@googlegroups.com
JS_THREADSAFE is a compile-time option that enables support for running multiple threads of JavaScript code concurrently as long as no objects or strings are shared between them.
We have recently made major changes to this feature. Until recently, sharing objects among threads would mostly work, although scripts could easily make it crash. We have now completely removed that feature. Each thread that uses the JavaScript engine must essentially operate in a totally separate region of memory.
https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JSRuntime
Only one thread may use a JSContext at a time.
I don't see how this would be more permissive than V8's threading rules. Multiple isolates allow for concurrent execution of JS in isolated regions. I suspect you might get lucky in SpiderMonkey if you share read-only objects but the docs clearly prohibit it.
Matthias
--
Reply all
Reply to author
Forward
0 new messages