We could streamline and make XPConnect's code much simpler if there was a callback provided that was called when a JSContext is created or destroyed. Right now, XPConnect has to go through and match up its contexts with the JSContexts and cleanup them up. Currently XPConnect relies on clients to call XPConnect on new contexts, and generates a assertion if that's not done. This is so it can place the "Components" property on the global object. This could happen automatically with such a callback.
Reassigning; cc'ing Brendan on this request -
Not all contexts created in a runtime would want the Components object, though -- how would you know which ones to skip? /be
I wasn't sure how often JSContexts were created that would never be used by XPConnect. A notification on destruction would be beneficial. Either a global callback, or a callback provided when the context was created. This would still make life a lot simpler for XPConnect, and eliminate much of the sync context code that we have now. I doubt it would be much of a code size win, but it would simplify and eliminate the need for most if not all of the sync context code that exists in XPConnect.
This was implemented in bug 342737, wasn't it?
(In reply to comment #4) > This was implemented in bug 342737, wasn't it? Yes.
Should this bug really be duped? This bug was more about streamlining xpconnect's context logic. The callbacks were just one way of doing that. Given that we now have the callbacks there's work that could be done to XPConnect to change the way XPConnect sync's the contexts. It might prove to be a nice little perf win.
> Given > that we now have the callbacks there's work that could be done to XPConnect to > change the way XPConnect sync's the contexts. It might prove to be a nice > little perf win. See bug 408539. It may not be a performance win, but at least it simplifies code a lot.