XPCOM Shutdown: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 15: Line 15:
   <th>Description
   <th>Description
   <th>Component Manager
   <th>Component Manager
   <th>Event Queues
   <th>Main Event Queue


<tr>
<tr>
Line 38: Line 38:
   <th>Eventq shutdown
   <th>Eventq shutdown
   <td>The main event queue stops accepting events. All remaining events on the main event queue are processed.
   <td>The main event queue stops accepting events. All remaining events on the main event queue are processed.
   <td>No events accepted
   <td rowspan="5">No events accepted


<tr>
<tr>
   <th>XPCOM Component Shutdown
   <th>XPCOM Component Shutdown
   <td>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.
   <td>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.
   <td>No calls allowed.
   <td rowspan="4">No calls allowed.


<tr>
<tr>

Revision as of 17:28, 14 November 2005

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.

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 static or module-wide COMPtr, not member comptrs).

XPCOM Shutdown Sequence

Step Description Component Manager Main Event Queue
xpcom-shutdown notification Initial notification of xpcom shutdown... during this observer topic all primary modules should begin shutdown and should release any root references. All calls allowed Events accepted
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-loader-shutdown notification Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules.
Binary component unload The static and binary component loaders will unload the binary components