XPCOM Shutdown
From MozillaWiki
This page describes the shutdown sequence of XUL apps. The goal of these notifications is to quit the application quickly with as little indeterminate behavior as possible. In debug builds, the app should shut down cleanly so automated tools can verify that there are no leaks.
Terms
- primary module
- An XPCOM module which is not a component loader
- root reference
- A reference to an XPCOM object in a module, which is not being held as a result of an external XPCOM reference (i.e. a cached service or static pointer, not member comptrs).
XPCOM Shutdown Sequence
| Step | Description | Profile State | Main Event Queue | Component Manager | Function calls across components | Notes |
|---|---|---|---|---|---|---|
| profile-change-net-teardown notification | Notification(s) that any unsaved user data should be saved | Profile access allowed | Events accepted | All calls allowed | Calls across components allowed | bsmedberg note: other than historical momentum, I don't think we need three separate notifications. |
| profile-change-teardown notification | ||||||
| profile-before-change notification | Future plans: after this notification, release builds will _exit()! | |||||
| xpcom-will-shutdown notification | Notification of the coming xpcom shutdown... during this topic observers can mark themselves as being destroyed. | No profile access allowed | This description is unclear; there is only one consumer of this notification: the appshell service prevents new windows from opening after it is delivered. | |||
| xpcom-shutdown notification | Initial notification of xpcom shutdown... during this observer topic all primary modules should begin shutdown and should release any root references.
| |||||
| Event Processing | All events on the main event queue are processed | |||||
| xpcom-shutdown-threads notification | Any non-main-thread event queues should be finished by the module which owns them. All threads running XPCOM code should be joined. Any special services that might be required for component loader shutdown should be obtained and cached by the end of this notification. Initial garbage collection should be performed at this stage. | |||||
| Event Processing | All events on the main event queue are processed | |||||
| Eventq shutdown | The main event queue stops accepting events. All remaining events on the main event queue are processed. | No events accepted | ||||
| XPCOM Component Shutdown | The following XPCOM components which hold global references will be shut down: service manager, component manager, observer service. nsIModules are released except for component managers, and all nsIObservers are release except those for which the last two notifications must be given. | No calls allowed. | ||||
| xpcom-shutdown-gc notification | A final GC should be performed by component loaders. This notification may be repeated if observers indicate GC roots still exist; TODO: how do they indicate this? Any outstanding roots through XPCOM references should be asserted and forcibly invalidated if necessary. | |||||
| xpcom-shutdown-loaders notification | Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules. | Function calls across components not allowed | ||||
| Binary component unload | The static and binary component loaders will unload the binary components |
