must unload JS components otherwise lots of evil leaks. this means shutting down the js component loader.
Why is this? What leaks? In today's xpconnect killing the JSContext of the wrapped JS object will cause xpconnect to release its root on the object (if it is holding one) and to make the JS object unreachable via xpconnect. Native 'users' of the object still hold a reference to a wrapper, but the wrapper will return a failure code on all method calls. This is generally whacky. And will be fixed in time. It will not work that way in the future. After xpconnect is fixed, xpconnect will hold its root as long as the JSRuntime of the JS object is alive and any native code has a reference to the wrapper for the JS object. This is not a leak. It is use. Given the current state where killing the JSContext blindly 'kills' the link between the user of the object and the object, how do you decide which components to kill and/or when to unload the loader? In the future scheme unloading the loader leaves the components which are in use in place. However, reloading the loader and instantiating the 'same' service implemented in JS will potentially cause two different implementation object of the same service (implemented in JS) to be running at the same time. This violates the 'service contract' :) This state is to be avoided. My original plan was to have the loader ask the js module if it wants to be unloaded or not and then respect its decision. It *any* of the loaded JS modules want to stick around, then the loader should not unload. Please explain why this is a problem. It seems to me that the only cost we will pay is the cost of keeping the loader around and the cost of holding on to any js modules that refuse to be unloaded. This is pretty much the same as the native case. I think, that shutting down the loader (except on final shutdown) would be right nasty.
Status: NEW → ASSIGNED
We're talking about final shutdown, where all the various items entrained by the JSContext and component-globals appear to leak, thus causing much grief for purify-users.
Depends on: 14656
I've got the shutdown routines running, but I don't get called in the interesting cases. The saga continues....
m12. let me know if fix becomes available in the next couple of days.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.