Subj : Re: Puzzling assertion in js_AllocGCThing() To : netscape.public.mozilla.jseng From : "Bob Kline" Date : Sat Mar 13 2004 08:08 am "Brendan Eich" wrote in message news:40525EA9.1050804@meer.net... > Sure -- the GC is single-threaded and must interlock with allocators. > Also, an allocator can't nest from a finalizer called from the GC. > > If you have an allocator racing with the GC, you're not using the > request model (JS_BeginRequest etc.) properly. But more likely, a > finalizer is allocating new objects. That's not allowed, although > several years ago it was. Brendan: 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. Looking at the docs for JS_BeginRequest, I see that it's intended to be invoked when the application starts a new thread. 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? 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? 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? Thanks again! Bob .