Closed
Bug 239875
Opened 21 years ago
Closed 21 years ago
Fix xpconnect static guards so we can restart
Categories
(Core :: XPConnect, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha2
People
(Reporter: benjamin, Assigned: benjamin)
References
Details
Attachments
(1 file)
(deleted),
patch
|
shaver
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
XPconnect currently has static guards to prevent it from restarting. I have a patch that makes xpconnect restartable (so that I can restart XPCOM for the semi-single-profile proposal, see attachment 144252 [details]). I'm not trying to make xpconnect shut down cleanly in this patch... only when we restart xpconnect through the generic-module-constructor, we re-initialize all the static. We will end up leaking a couple of xpconnect implementations, but that can't be helped without reworking the entire xpcom shutdown sequence (bug 180380).
Assignee | ||
Comment 1•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #145610 -
Flags: superreview?(brendan)
Attachment #145610 -
Flags: review?(shaver)
Assignee | ||
Updated•21 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.7final
Assignee | ||
Updated•21 years ago
|
Blocks: semi-single-profile
Comment on attachment 145610 [details] [diff] [review] Init static guards on xpconnect restart I think this looks fine. If it actually made Mozilla restart xpconnect at some point, I'd be a lot more nervous. r=shaver
Attachment #145610 -
Flags: review?(shaver) → review+
Comment 3•21 years ago
|
||
I'm wondering what happens to all the the maps between JS object and natives and maps between other internal parts of XPConnect are no longer accessible, since the runtime service has been cut loose. Depending on when this is called, and how many wrapped objects exist, you could leak a fair amount of data in the maps. And since the maps are gone, you'd be leaking the objects wrapped by XPConnect since the GC would never be able to get to them. XPConnect contexts would be leaked as well as duplicated. You'll probably be duplicating any native sets as well. That's a few things off the top of my head. A similar issue raised a while back by an embedder was having two JS engines running within the same process. The statics in XPConnect presented a hurdle to doing this, as did some other issues. I'm just wondering if it would worth taking a look at it from that view and possibly coming up with a cleaner solution. Unfortunately that probably doesn't meet your time frame.
Assignee | ||
Comment 4•21 years ago
|
||
I don't know this code well enough to be sure why we're not leaking, but I've instrumented leakages and the maps are definitely not holding on to lots of stuff. The only thing we leak is one instance of xpccomponents and one nsXPConnect, at least in the controlled circumstances of the profile manager and migration.
Comment 5•21 years ago
|
||
Comment on attachment 145610 [details] [diff] [review] Init static guards on xpconnect restart Sure, why not? But I bet we have other statics (perhaps you've checked for function-scope statics?). If we ever do decide to do a "hot restart", we really need a more stylized convention for static data, that groups it into a "statics" class per XPCOM module, or some such thing. /be
Attachment #145610 -
Flags: superreview?(brendan) → superreview+
Assignee | ||
Comment 6•21 years ago
|
||
Fixed on trunk
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.7final → mozilla1.8alpha2
You need to log in
before you can comment on or make changes to this bug.
Description
•