On Sat, Jun 30, 2012 at 01:20:01PM +0200, Ole wrote:
this patch tries to avoid repeated initialization of JS context,
altough there is already one setup.
Maybe an assert(JS_GetGlobalObject(cx) == NULL) would be better
here, because js_newcompartment is not intended to be called twice
on the same context?
(fixes an failed assert in spidermonkey when reloading the page)
You have completely missed whats going on here, the code there is correct.
let me explain:
The whole browser has a single library instance known as the "runtime"
created with JS_NewRuntime().
Each browsing context, as defined by the DOM (in our case a browser
created upon teh runtime with JS_NewContext()
The lifetime of this context is directly coupled to the browser
window, though I have arranged delaying the creation of the context
new contexts is a relatively expensive operation so it is worth
delaying it as long as possible.
"window" object within a browser to which all the other browser
context is attached (document, console etc. etc.) it is created with
JS_NewCompartmentAndGlobalObject(). The global is created within a
created afresh when a root content (the content which is caused to be
loaded by navigating to a new page in the browser window) aquires the
context from its containig browser window.
The loading content only does this once when it initialy comes across
the browser window for a context and we avoid the overhead of creating
a fresh global).
The content *must* be given a fresh global object or the content will
not be starting from the state the previously loaded page left it!
complete with pointers to the previous DOM tree etc.
The spidermonky authors indicated that from the 1.8 series onwards the
global object is garbage collected when replaced and I did not need to
perform any additional housekeeping.
I suspect that previous editions may need the user to explicitly mark
the global as ready for destruction before it is replaced. This should
be put in as JS_VERSION conditional code within jsapi.h which