[Edbrowse-dev] JSAutoRequest

[Edbrowse-dev] JSAutoRequest

[Karl Dahlke]

JSAutoRequest is in Chris hello world program, but not in edbrowse.
What does it do? Do we need it?

emptyArgs[] in jsdom.cpp is not used, can we delete it?

Chris is on the mark when he says we still need to get this working
with debian packages, though I think we will need their help to procede.
How do they build their js24 library?
Is it possible that they built their library with js_config.h
somehow different from the one that is in their distribution?
That would cause trouble.
I was thinking of tweaking this file, and build hello world, to see if it helps.
IDK

Karl Dahlke

Re: [Edbrowse-dev] JSAutoRequest

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> JSAutoRequest is in Chris hello world program, but not in edbrowse.
> What does it do? Do we need it?

I went looking, but at first, I didn't find much.  So I looked at the
implementation.  JSAutoRequest is just a RAII wrapper around
JS_BeginRequest and JS_EndRequest.  Here's what the Mozilla docs say
about JS_BeginRequest:

<quote>
When your multithreaded application wants to use a JSContext,
it must use JS_BeginRequest and JS_EndRequest to bracket maximal non-blocking
hunks of native code that call the JSAPI.
This "request model" is necessary to interlock with the global garbage collector.

In a JS_THREADSAFE build, many JSAPI functions must only be called from within a request.
In this reference, the cx parameter of such functions is documented with the
phrase “Requires request”, like this:

Name|Type|Description
cx|JSContext *|The context to use. Requires request.
In a {JS_THREADSAFE} build, the caller must be in a request on this JSContext.

In a DEBUG build, this is enforced with assertions.

Requests constrain garbage collection.
If any thread is in a requests, garbage collection can happen only when that
thread calls into the JSAPI. If one thread needs garbage collection,
it blocks until each other thread makes a JSAPI call.
It is therefore imperative that native code executing within an active request
on cx not block, or simply take too long, outside the JSAPI.
Any blocking native call, or lengthy computation that can race safely with the
garbage collector, within a request,
must be bracketed with {JS_SuspendRequest} and {JS_ResumeRequest}.

It is safe to nest calls to JS_BeginRequest so long as each call is balanced by
a matching call to JS_EndRequest.
</quote>

edbrowse isn't multithreaded, so we don't have to worry about multiple
threads calling into JSAPI.  But it looks like we still need to worry
about requests, since the user's Spidermonkey may have been built with
JS_THREADSAFE.  In fact, I'm fairly certain that everyone is going to
use JS_THREADSAFE builds.

I think it would be ok to put:
JSAutoRequest autoreq(cw->jss->jcx);
just before the JSAutoCompartment call in SWITCH_COMPARTMENT.
Also we need a JSAutoRequest autoreq(state->jcx); just after state->jcx
is successfully initialized in createJavaContext.
Does that all seem reasonable?

-- Chris

Re: [Edbrowse-dev] JSAutoRequest

[Adam Thompson]

On Sun, Feb 23, 2014 at 06:38:08AM -0800, Chris Brannon wrote:
> edbrowse isn't multithreaded, so we don't have to worry about multiple
> threads calling into JSAPI.  But it looks like we still need to worry
> about requests, since the user's Spidermonkey may have been built with
> JS_THREADSAFE.  In fact, I'm fairly certain that everyone is going to
> use JS_THREADSAFE builds.
> 
> I think it would be ok to put:
> JSAutoRequest autoreq(cw->jss->jcx);
> just before the JSAutoCompartment call in SWITCH_COMPARTMENT.
> Also we need a JSAutoRequest autoreq(state->jcx); just after state->jcx
> is successfully initialized in createJavaContext.
And one in html.cpp
> Does that all seem reasonable?

Yep, implemented, committed and pushed.

Cheers,
Adam.