Subj : Re: JavaScript/XPCOM and mutithreading....
To   : Jean-Marc Paulin
From : Brendan Eich
Date : Sat Dec 04 2004 05:37 pm

Jean-Marc Paulin wrote:

>   I can compile with any context, and execute with any context.
>   So what is the best ?
>   - 1 cx and 2 threads, and some SetContextThread(), or
>   - 2 cx and 2 threads ? (which is in fact always reuse the same context 
> with the same thread ?).


The latter is easier, and it is more efficient if you are going to do JS 
on both threads unpredictably.  For N threads, you could have a pool of 
M JSContexts, M <= N, and affinity of context and thread based on which 
threads are doing JS.


> In that case, wouldn't javascript variable value 
> ('var blah="blah";') defined in the javascript source been lost, function of 
> which thread/context is used ?


No.  Compiling does not bind variables.  Execution does.  This is 
necessary per the ECMA-262 spec, even though that spec does not model 
compilation as separable from execution.


> - This is a question: what is nsIJSContextStack/nsIJSThreadContextStack
> ????, why do I use it? what is it supposed to do ? Do I really need this ?


Consider when you have native function N1 that calls into the JS API, 
passing a JSContext *cx, to evaluate a script, which may then call a 
native method that calls another native function N2.  N2 does not take a 
JSContext *cx parameter.  Interesting examples here include modal dialog 
functions, and of course N2 is usually a tree of native methods and 
functions that call or are called by the initial JS native.

Now N2 wants to do JS, acting on behalf of the script that initiated the 
control flow into N2.  For security and consistency, the same JSContext 
ought to be used, unless and until a new window or other context-owning 
document container has been created, and other script(s) loaded into it 
and evaluated.

The XPConnect nsIJSContextStack stuff is exactly the thread-local 
storage abstraction that helps N2 find the JSContext *cx that N1 used.


>   This is because I have a XUL application, and the user may start some 
> intensive work.
>   (long time consuming DB Query and more glued together using Javascript
> ;) ) so to not
>   lock the UI during those, I create a new thread to perform long term 
> operations. But
>   sill want to compile the script in interactive mode. By design, the script 
> is executed
>   either in the main thread, or in a dedicated background thread (prefered). 
> I have put
>   some semaphore around to prevent running a script on 2 threads. So I 
> should be fine.


What does this script do?  If it's not running on the main thread, it 
can't use the DOM or most other Gecko XPCOM-fronted code.


>   Now you said it should work?, well, it kind of does, but I keep getting 
> stuff like:
> 
> ---------------------------------------------------------------
> !!!!! XPConnect wrapper thread use error...
>   XPConnect WrappedNative is being accessed on multiple threads but the 
> underlying native xpcom object does not have a nsIClassInfo with the 
> 'THREADSAFE' flag set


As I said, most of Gecko is not threadsafe.

What is the background thread computing, and what data dependencies do 
its scripts have?

/be

.