XPCOM Shutdown: Difference between revisions

add profile notifications
(add profile notifications)
Line 1: Line 1:
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.
This page describes the startup and shutdown sequence of XUL apps. The goal of these notifications is to start and 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.
 
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 ==
== Terms ==
Line 16: Line 12:
   <th>Step
   <th>Step
   <th>Description
   <th>Description
  <td>Profile State
   <th>Main Event Queue
   <th>Main Event Queue
   <th>Component Manager
   <th>Component Manager
   <th>Function calls across components
   <th>Function calls across components
  <th>Notes
<tr>
  <th><tt>profile-change-net-teardown</tt> notification
  <td rowspan="3">Notification(s) that any unsaved user data should be saved
  <td rowspan="3">Profile access allowed
  <td rowspan="8">Events accepted
  <td rowspan="9">All calls allowed
  <td rowspan="11">Calls across components allowed
  <td><em>bsmedberg note: other than historical momentum, I don't think we need three separate notifications.</em>
<tr>
  <th><tt>profile-change-teardown</tt> notification
<tr>
  <th><tt>profile-before-change</tt> notification
  <td><em>After this notification, release builds will _exit()!</em>


<tr>
<tr>
   <th><tt>xpcom-will-shutdown</tt> notification
   <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>Notification of the coming xpcom shutdown... during this topic observers can mark themselves as being destroyed.
   <td rowspan="5">Events accepted
   <td rowspan="10">No profile access allowed
  <td rowspan="6">All calls allowed
   <td>This description is unclear; there is only one consumer of this notification: the appshell service prevents new windows from opening after it is delivered.
   <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="7">Calls across components allowed
 


<tr>
<tr>
Confirmed users, Bureaucrats and Sysops emeriti
1,217

edits