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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
_______________________________________________
Mozilla-xpcom mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-xpcom
