Subj : Re: Access violation in JavaScript-C 1.5 pre-release 5 2003-01-10 for Win32 To : netscape.public.mozilla.jseng From : "Rob Swindell" Date : Tue May 06 2003 06:41 pm "Brendan Eich" wrote in message news:3EB8333F.40307@meer.net... > > >If the JS engine doesn't use any global or static variables, and a separate > >runtime is used per thread, why would there be any "thread safety" issues? > >Sorry for questioning your answer, but I just don't understand what > >necessitates the requirement. :-) > > > > > > The deflated string cache. Because of very old (older than > JS_THREADSAFE) API commitments in the form of JS_GetStringBytes and its > many clients, that cache is global. Notice the lack of a cx or rt > parameter to JS_GetStringBytes. Is there a thread-safe alternative to JS_GetStringBytes that can be used instead (or any plans to introduce one)? > >If a separate runtime is used per thread, no JS_BeginRequest/EndRequest > >calls are required though, correct? > > > > > > Correct. But you can't share objects among runtimes, and you waste more > memory on average than if you could share. > > So since you'll need JS_THREADSAFE anyway, why not use fewer (say, one) > runtimes? I did have it coded that way at first (using JS_BeginRequest/EndRequest too) but ran into frequent crashes during GC. I came here for solutions, but in the end, separate run-times per thread seemed to be best solution. If I have to resort to the NSPR/JS_THREADSAFE build again (which it sounds like), then I might again try using a single run-time for all threads. -Rob .