Subj : Re: Puzzling assertion in js_AllocGCThing() To : Bob Kline From : Brendan Eich Date : Sat Mar 13 2004 02:04 pm Bob Kline wrote: > Thanks very much for your response. Please bear with me while I come up to > speed. None of the code which is using the SpiderMonkey engine belongs to > us (it's the Sablotron XSLT package, but fortunately it's open source), so > I'm new to the SpiderMonkey API. Who owns sablotron? Where is it hosted? I should google, but you can probably direct me better. > Looking at the docs for JS_BeginRequest, I see that it's intended to be > invoked when the application starts a new thread. Argh, the docs are misleading here. The rule for JS_THREADSAFE embeddings is that you must bracket hunks of API calls embedded in native code with requests, suspending around blocking i/o or other long-running or blocking code. You want to amortize request overhead well while not making any request run to completion for too long (us or ms, never seconds). > In our application, there > wouldn't be any way for the Sablotron code to know reliably when a new > thread has been started. Processing looks like this: > > Server receives a command from a client > Server creates a new thread to process the command > For each XSLT script filtering needed for command processing: > Invoke the Sablotron engine > > So presumably the Sablotron code wouldn't want to take the docs literally, > but instead should invoke JS_BeginRequest once for each time we invoke it > from our application. Is this right? Yes, or better: et Sablotron to add requests at the right granularity within their code, since it is their code that embeds SpiderMonkey in a JS_THREADSAFE mode. But if you have to work around their lack of requests, you should be able to do it. Provided the Sablotron engine invocation never blocks, or takes too long. > Once JS_BeginRequest and JS_EndRequest have been wrapped around JS > processing code is it then safe for the Sablotron to invoke JS_GC or > JS_MaybeGC at arbitrary points in its code? Yes, although it may be inefficient if they call too often, or when there are bound to be lots of requests running (GC waits for all active requests to suspend or end, then gets its foot in the door so no new or suspended requests can begin or resume, then collects garbage, finally notifying pending requests when done). > I don't see any guidance in the > documentation for these two functions for interacting with threads. Is > there more comprehensive documentation on this topic to which we could > direct the Sablotron team? Are there other aspects of the SpiderMonkey > engine which are thread-sensitive? When you compile with JS_THREADSAFE defined, you need to link with NSPR. I'm assuming that the Sablotron embedding does this, but maybe it's just using thread-unsafe SpiderMonkey? That would be very bad. /be .