XPCOM Shutdown: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(restore table end-tag)
Line 19: Line 19:
   <th>Component Manager
   <th>Component Manager
   <th>Function calls across components
   <th>Function calls across components
<tr>
  <th><tt>xpcom-will-shutdown</tt> notification
  <td>Notification of the coming xpcom shutdown... during this topic observers can mark themselves as being destroyed, but they must not spin event loop.
  <td rowspan="5">Events accepted
  <td rowspan="6">All calls allowed
  <td>No event loop spinning


<tr>
<tr>
   <th><tt>xpcom-shutdown</tt> notification
   <th><tt>xpcom-shutdown</tt> notification
   <td>Initial notification of xpcom shutdown... during this observer topic all primary modules should begin shutdown and should release any root references.
   <td>Initial notification of xpcom shutdown... during this observer topic all primary modules should begin shutdown and should release any root references.
  <td rowspan="4">Events accepted
  <td rowspan="5">All calls allowed
   <td rowspan="7">Calls across components allowed
   <td rowspan="7">Calls across components allowed



Revision as of 19:21, 24 November 2009

The goal: to cleanly shut down XPCOM components, including component loaders, so that all cross-module references are cleaned up and the component DLLs can be unloaded.

The problems: the current "xpcom-shutdown" notification is not sufficient because component loaders cannot unload until all their loaded components are first unloaded. In addition GC does not happen until very late, while we're in the middle of destroying the component manager.

Bug: bug 316414

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 Main Event Queue Component Manager Function calls across components
xpcom-will-shutdown notification Notification of the coming xpcom shutdown... during this topic observers can mark themselves as being destroyed, but they must not spin event loop. Events accepted All calls allowed No event loop spinning
xpcom-shutdown notification Initial notification of xpcom shutdown... during this observer topic all primary modules should begin shutdown and should release any root references. Calls across components allowed
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