Subj : Re: Access violation in JavaScript-C 1.5 pre-release 5 2003-01-10
To   : Rob Swindell <jseng@synchro.net>
From : Brendan Eich <brendan@meer.net>
Date : Wed May 07 2003 03:02 pm

Rob Swindell wrote:

>"Brendan Eich" <brendan@meer.net> 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)?
>  
>

There are other places (a few) that have globals needing protection 
under JS_THREADSAFE (jsarena.c, jsdtoa.c).

Adding a thread-safe alternative API wouldn't work unless we supported a 
way to #ifdef off the old API, but we don't break API compatibility 
lightly.  Apart from JS_THREADSAFE (which did require a change or two 
when it went in), we've kept API compatibility to a degree that 
satisfies every embedder I've heard from, for more than six years now, 
AFAIK.

>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.
>  
>

Please do, and I'll help work through the request problems.  If you're 
able to use C++, you might benefit from a JSAutoRequest helper class, by 
which you can say

    {
        JSAutoRequest req(cx);
        do stuff within a request, including early returns from within 
loops;
    }

and you won't need to hassle with balancing JS_BeginRequest and 
JS_EndRequest.  Also, the JS_PARANOID_REQUEST macro can now be defined 
(trunk SpiderMonkey, probably in the last RC too) to insist on every API 
call that must run within a request, that a request is active.  So 
you'll want to turn that on at the first sign of trouble, or just for a 
coverage test run or two.

/be

>-Rob
>
>
>  
>

.