Subj : Re: JavaScript/XPCOM and mutithreading.... To : netscape.public.mozilla.xpcom,netscape.public.mozilla.jseng From : Jean-Marc Paulin Date : Sat Dec 04 2004 11:33 am Whaoo, Thanks alot for all those explainations. But this raises few more ;) (Sorry /be) - I got the context (cx) idea (I think), and JS_SetContextThread(). And only one thread at a time may use a context. The global object is associated with a given context, as part of the JS_InitStandardClasses(). 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 ?). 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 ? - This is a question: what is nsIJSContextStack/nsIJSThreadContextStack ????, why do I use it? what is it supposed to do ? Do I really need this ? - a bit of background: > 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? 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. 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 wrapper: [object nsXPCComponents @ 0x2764218] JS call stack... 0 [native frame] 1 writetofile(filename = "c:\test3.txt") ["":17] file = [xpconnect wrapped nsILocalFile @ 0x209fd28] of = undefined result = undefined this = [object global] this.onPreExecute= [function] this.writetofile = [function] this.str = "This is the 2nd line now !!!" 2 onPreExecute() ["":32] this = [object global] this.onPreExecute= [function] this.writetofile = [function] this.str = "This is the 2nd line now !!!" 3 [native frame] --------------------------------------------------------------- Why would that be ? Which nsIClassInfo is it moaning about? How do I fix it ? (I need the 2 threads stuff for UI reasons). Many thanks JM Oh, I've noted Samuel's quote. I won't ass-?????? Anymore ;) Ta, "Brendan Eich" wrote in message news:41AFD4CC.6080501@meer.net... > 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 .