SpiderMonkey: Multithreading question
Franky Braem
The design is as follows:
On startup of the module I create a JSRuntime and initialize all the
classes.
Each request creates a context and creates a dummy object that will be
used as scope object for each script that is associated with the
request. When the request is handled this context is destroyed.
All my C++ classes are ported by several DLL's. Some of the DLL's have
their own context for calling functions that are attached as a property
on a ported object. For example, the wxDir object has a onFile property
which can be used to traverse a directory. Each handler is run in a
separate thread, so it is possible that more then one thread will
execute the function at the same time. My question: Is this save? Should
I create a new context everytime I try to execute the onFile function?
Or must I use JS_THREADSAFE?
Franky.
Brendan Eich
> I'm trying to write an Apache module for my wxJS port.
> The design is as follows:
>
> On startup of the module I create a JSRuntime and initialize all the
> classes.
>
> Each request creates a context and creates a dummy object that will be
> used as scope object for each script that is associated with the
> request. When the request is handled this context is destroyed.
You probably will want to pool contexts to threads and reuse them.
> All my C++ classes are ported by several DLL's. Some of the DLL's have
> their own context for calling functions that are attached as a property
> on a ported object.
Why wouldn't you use the context on which the particular native function
was called? Why does a DLL have a context? Contexts are for JS script
execution, they contain the interpreter stack and virtual registers.
They shouldn't be created unnecessarily, both for economic reasons and
to avoid bugs where you fail to propagate the right state from caller
context to callee context (e.g., globalObject, if you use it, private
data, etc.).
> For example, the wxDir object has a onFile property
> which can be used to traverse a directory. Each handler is run in a
> separate thread, so it is possible that more then one thread will
> execute the function at the same time. My question: Is this safe?
It's certainly safe to execute the same script in multiple threads
concurrently, using a separate JSContext per thread. The script and its
subsidiary structures are immutable.
> Should
> I create a new context everytime I try to execute the onFile function?
> Or must I use JS_THREADSAFE?
You absolutely need JS_THREADSAFE -- why did you think you didn't?
/be
Franky Braem
>
>
> You absolutely need JS_THREADSAFE -- why did you think you didn't?
I'm using a pool of contexts now. Each request thread reserves a
context. Other threads can't use this reserved thread, unless the thread
has unlocked it. Do I need JS_THREADSAFE when I'm sure that a context
can only be used in one thread?
Brendan Eich
Again, yes -- and you can't use a context by more than one thread at a
time in any event.
The context is just interpreter state: a stack of bytecode pointer (pc),
scope chain, etc. It is therefore a single-threaded data structure.
You need at least one per thread concurrently executing JS.
Objects live in the runtime, which contains the contexts and the GC heap
containing all objects. You need at least one per process.
Since there are objects and data structures in the runtime shared among
threads using contexts, you need JS_THREADSAFE for any multi-threaded
embedding. Even if you used one runtime per thread, at present you need
JS_THREADSAFE because [*] some global data structures are shared among
all threads, no matter how many runtimes you use (that is, even if you
have one runtime *and* one context per thread).
/be
* For API backward compatibility, and due to how this was achieved in
the current implementation -- so possibly fixable with better ideas, but
the rule is: use JS_THREADSAFE if your embedding allows multiple threads
to execute JS concurrently.