Subj : Re: JavaScript/XPCOM and mutithreading....
To   : netscape.public.mozilla.xpcom,netscape.public.mozilla.jseng
From : Richard Klein
Date : Fri Dec 10 2004 11:58 am

Brendan Eich wrote:
> 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
For those long time scripts, you could create an component with 
observers or listeners.

.