Subj : Re: global hash table
To   : netscape.public.mozilla.jseng
From : Shanti Rao <shantirao@yahoo.com>
Date : Thu Feb 19 2004 03:26 pm

I am thinking about writing a database-backed web server using SpiderMonkey.

I am interested in the global variables because one thread might get stuck in 
a loop, and I want to be able to kill it gracefully.

Thanks,

Shanti

Brendan Eich wrote:
> Shanti Rao wrote:
> 
>> Hi Brendan,
>>
>> Why are script_filename_table, deflated_string_cache, etc. global C 
>> variables instead of properties of a runtime?
> 
> 
> 
> Two questions (etc. doesn't count, you have to be specific), two answers:
> 
> 1.  script_filename_table is global because script filenames are part of 
> a global (per machine) filesystem, so can be shared across runtimes.  A 
> lock would be required to serialize critical sections accessing and 
> updating the table in the case that the table is in a runtime, so 
> there's no locking penalty in using a global instead of a per runtime.  
> But since a given filename may be compiled in several runtimes, the 
> sharing benefit of a global table favors the global approach over the 
> per-runtime way.
> 
> 2.  deflated_string_cache came in when the very early (1996) 
> SpiderMonkey codebase was extended to do Unicode 2 from ISO-Latin-1.  
> The existing JS_GetStringBytes API lacks a cx or rt parameter, so there 
> is no way a runtime member could be used for the deflated string cache 
> (and again, there is a sharing win in the case of two strings in two 
> runtimes being deflated -- but the API constraint was the real 
> motivating factor, not any sharing benefit).  API compatibility trumps 
> anti-global animus.
> 
> Why do you ask, anyway?
> 
> /be

.