Subj : Re: Can I have more than one runtime to facilitate multiple threads? To : Chris Davis From : Brendan Eich Date : Tue Jul 01 2003 09:45 am Chris Davis wrote: > Brendan Eich wrote in message news:<3F00A524.5050206@meer.net>... > > >>What locks? What stacks? > > > We were concerned with all JS code that issues locks from the single > runtime > I had in the threaded version. For example, JS_LOCK_GC(rt) out of > JS_BeginRequest(). Based on reading the code, or on profiling or other measurement? JS_BeginRequest and JS_EndRequest can be amortized over enough cycles in typical embeddings, that the overhead in those two API calls is in the noise. Batching up API calls and executing as many as do not block in a single request is a good idea. Also, most embeddings do non-trivial work in precompiled scripts and functions (event handlers), so wrapping each such script execution or function call in a request does not add too much cost. Requests can run in parallel with one another, but not with the GC, and not with a request wanting to operate on an object owned exclusively (and therefore subject to the lock-free optimization) by another request (one that created the object, or claimed it from a previous request that was no longer exclusively owning it). Are any objects in your embedding shared among contexts (and therefore possibly among concurrently active requests)? How are you calling JS_BeginRequest and JS_EndRequest? >>How do you know where the CPU was in the single-process case? > > Admittedly, only via process of elimination as we looked at the code. > It was obvious that hundreds of threads were making tons of calls to > JS_ResumeRequest > and JS_SuspendRequest for different contexts all derived from a single > runtime. How was it obvious? Why Resume and Suspend? Can you say more about how those two APIs are being called (how often, and in what circumstances)? > In my case I had 200+ threads using the single run time object. Would > that optimization have helped the run time's locks? No, it helps object locking only. Runtime locks are not held for long, and again you should be able to amortize request interlocking overhead. It sounds like maybe request granularity was too small, or perhaps you had to suspend and resume in a frequently-called native function or set of functions. I might be able to help more if I knew why that was. /be .