Subj : Re: JavaScript/XPCOM and mutithreading....
To   : jmp
From : Brendan Eich
Date : Thu Dec 02 2004 06:51 pm

jmp wrote:
> Hi,
> 
>  
>  Well, I initially assumed that Javascript is not built-in with much thread-safe stuff in it, but
>  was wondering where the limit of multithreading was.


Why assume?  As Samuel L. Jackson said, when you make an assumption, you 
make an ass out of you and umption ;-).  See 
http://lxr.mozilla.org/mozilla/search?string=JS_THREADSAFE -- see also 
the API docs under http://www.mozilla.org/js/spidermonkey/.


>  The JS_SetContextThread( cx ) lead me to believe that only 1 cx can be executed at a time: fine!


False, so not fine.

Only one thread may use a context at a time -- a context is a 
thread-local data structure (you may reassing a context from one thread 
to another of course, pooling contexts to avoid destroying and 
recreating them excessively -- wherefore JS_SetContextThread).


>  So I was wondering:
> 
>  Could I have: compile of the script on thread1 then using JS_SetContextThread( cx ), get the thread to execute on thread2 ?


This confuses scripts with contexts.  You may compile a script using any 
context, and execute it using any other.  There is no need to 
reassociate the context with which you compiled a script with another 
thread, just to run the script on that other thread -- nor is doing so a 
good idea, if the thread on which you compiled still might use that 
context (only one thread at a time may use a context).


>  and what do I do with the nsIJSContextStack? or will I need to create a nsIJSThreadContextStack per thread ?


The latter.


>  actually, what nsIJSContextStack is all about exactly anyway


Is that a question?


>  thread 1:
>   m_cx = JS_NewContext(m_rt, 8192);
>   ...
>   /* All the cooking for JS engine/principal/gloabl object...etc... */
>   ...
>   JS_CompileUCScriptForPrincipals(m_cx, m_glob, jsp , (jschar*)mScripts.get() , mScripts.Length() , "" , 0);
>   JS_ClearContextThread( m_cx );
>   
>  then a bit later,
> 
>  thread 2:
>   JS_SetContextThread( m_cx );
>   JS_ExecuteScript(m_cx, m_glob, m_script, &result);
>   JS_ClearContextThread( m_cx );


This will work, but why are you using one context and two threads?  If 
thread 1 and thread 2 execute concurrently *in the JS engine* (called 
via the JS API), then you need two contexts.  If not, then why do you 
need two thread?


>  And what about other objects/operations? are the globals defined in the javascript available
>  accross threads ?


Globals have no connection to contexts unless you create one using 
JS_SetGlobalObject or JS_InitStandardClasses.  So above, you presumably 
did use JS_InitStandardClasses in the /* All the cooking for JS 
engine/principal/... */ elision.  That global object is associated with 
m_cx even if you change m_cx's thread to thread 2.

But when you write "available across threads" above, you imply that that 
global is also available to thread 1.  Why?  JS is thread-safe, so 
nothing will go wrong in the engine, but how would two scripts running 
concurrently on threads 1 and 2 possibly synchronous reads and writes of 
global properties?

SpiderMonkey's multi-threaded support has been tested for years in 
various server embeddings, including big VXML services.  You can share 
objects across threads, but JS itself does not provide synchronization 
syntax and semantics to script authors, and most embeddings purvey an 
apparently-single-threaded, "run to completion" execution model to 
script authors.

This fits the target audience for JS, but it sometimes results in some 
"continuation passing" via explicit callbacks and chained event handlers 
and timeouts, e.g., via setTimeout in the DOM level 0.

What *exactly* is your embedding's intended execution model?  What is 
the target "script author" or "real programmer" audience?

/be

.