Subj : Re: Puzzling assertion in js_AllocGCThing()
To   : netscape.public.mozilla.jseng
From : "Bob Kline" <bkline@rksystems.com>
Date : Sun Mar 14 2004 11:15 am


"Brendan Eich" <brendan@meer.net> wrote in message
news:40538575.6000102@meer.net...
>
> Who owns sablotron?  Where is it hosted?  I should google, but you can
> probably direct me better.

Of course, sorry for the omission:

http://www.gingerall.com/charlie/ga/xml/p_sab.xml

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

I see.  Let me echo back my understanding of what you're saying.  Please
tell me how close I get to the truth, and set me straight if I'm all wet.

So, the calls JS_BeginRequest and JS_EndRequest tell the SpiderMonkey engine
that it's not safe to perform any operations (for example, garbage
collection) which must be single-threaded.  Since I don't see any indication
in the JS_ API as to which calls could trigger such operations, I have to
assume that the Begin/End bracket must surround *any* calls to the
SpiderMonkey package except, presumably, calls to create or destroy the
contexts and the runtime, since the runtime is needed to create the
contexts, and the context is needed for the calls to the Begin/End request
marker functions.  The pair JS_SuspendRequest and JS_ResumeRequest would be
used inside a Begin/End block for blocking or long-running native code which
is guaranteed *not* to have any JS_xxx calls in it.  So, in the Sablotron
engine, processing might need to look something like this to be thread-safe:

codeWhichUsesSpiderMonkey()
{
    JSContext* context = getOrCreateContext();
    JS_BeginRequest(context);
    JS_This();
    JS_That();
    JS_SuspendRequest(context);
    talkToDatabase(); // no JS_ calls allowed in here
    JS_ResumeRequest(context);
    JS_TheOther();
    JS_EndRequest(context);
}

Assuming I got it right so far (big assumption, I know), there's still a
couple of points on which I'm still fuzzy:

1. If the JavaScript package won't do garbage collection while any thread is
in an unsuspended request (as determined by these four JS_xxxRequest()
functions), then presumably calls to JS_GC() and JS_MaybeGC() would also
have to be placed outside the fenced-off request block.  Is this right?

2. From my reading of the JS_ API docs, I get the impression that if the
client code (Sablotron, in this case) never invokes either of the GC calls,
garbage collection will be done as needed anyway internally.  Is this
correct?

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

That's the plan.  In the past, when we're run into bugs in Sablotron, we do
what we would do with any open-source package we're using: provide as much
information about how to reproduce (and, in the ideal case, fix) the bug.
We have found that if we do as much of this sort of legwork ourselves, the
chances of getting the problems address promptly and correctly increase
dramatically, and it builds up valuable good will with the development team
for the package.

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

I don't think that would be feasible in the general case here, because XSL/T
processing of very large documents can easily go way beyond the milliseconds
threshold you were advising.  But I don't anticipate any reluctance on the
part of the Sablotron team to do the Right Thing here.

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

In fact, they were.  But they're willing to address that problem.

Thanks again for your patient and very clear explanations.

Bob

.