XPCOM Shutdown - Revision history

Benjamin Smedberg: clarify "will" to be aspirational

2014-04-14T19:33:46Z

clarify "will" to be aspirational

← Older revision		Revision as of 19:33, 14 April 2014
Line 32:		Line 32:
	<tr>		<tr>
	<th><tt>profile-before-change</tt> notification		<th><tt>profile-before-change</tt> notification
	<td><em>~~After~~ this notification, release builds will _exit()!</em>		<td><em>Future plans: after this notification, release builds will _exit()!</em>

	<tr>		<tr>

Skierpage: this is only shutdown; add See also link to XPCOM Startup

2012-03-06T04:49:53Z

this is only shutdown; add See also link to XPCOM Startup

← Older revision		Revision as of 04:49, 6 March 2012
Line 1:		Line 1:
	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.		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 ==		== Terms ==
Line 81:		Line 81:

	</table>		</table>

			== See also ==
			* [[XPCOM Startup]]

Benjamin Smedberg: add profile notifications

2012-02-28T19:04:14Z

add profile notifications

← Older revision		Revision as of 19:04, 28 February 2012
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>

Pettay: /* XPCOM Shutdown Sequence */

2009-11-24T19:21:07Z

XPCOM Shutdown Sequence

← Older revision		Revision as of 19:21, 24 November 2009
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

Dbaron: restore table end-tag

2007-03-18T16:51:38Z

restore table end-tag

← Older revision		Revision as of 16:51, 18 March 2007
Line 61:		Line 61:
	<th>Binary component unload		<th>Binary component unload
	<td>The static and binary component loaders will unload the binary components		<td>The static and binary component loaders will unload the binary components

			</table>

Dbaron: link to bug

2007-03-18T16:49:18Z

link to bug

← Older revision		Revision as of 16:49, 18 March 2007
Line 2:		Line 2:

	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.		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 ==

Efriedman: Ah well, the wiki doesn't like tables...

2007-03-09T20:57:06Z

Ah well, the wiki doesn't like tables...

← Older revision		Revision as of 20:57, 9 March 2007
Line 59:		Line 59:
	<th>Binary component unload		<th>Binary component unload
	<td>The static and binary component loaders will unload the binary components		<td>The static and binary component loaders will unload the binary components

	~~</td></tr></table>~~

Efriedman: Minor tag change to make Wiki happy

2007-03-09T20:55:20Z

Minor tag change to make Wiki happy

← Older revision		Revision as of 20:55, 9 March 2007
Line 60:		Line 60:
	<td>The static and binary component loaders will unload the binary components		<td>The static and binary component loaders will unload the binary components

	</table>		</td></tr></table>

MikeKaply at 14:36, 6 April 2006

2006-04-06T14:36:40Z

← Older revision		Revision as of 14:36, 6 April 2006
Line 52:		Line 52:

	<tr>		<tr>
	<th><tt>xpcom-~~loader~~-~~shutdown~~</tt> notification		<th><tt>xpcom-shutdown-loaders</tt> notification
	<td>Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules.		<td>Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules.
	<td rowspan="2">Function calls across components not allowed		<td rowspan="2">Function calls across components not allowed

Dbaron: /* XPCOM Shutdown Sequence */ better wording

2005-11-14T20:30:51Z

XPCOM Shutdown Sequence: better wording

← Older revision		Revision as of 20:30, 14 November 2005
Line 16:		Line 16:
	<th>Main Event Queue		<th>Main Event Queue
	<th>Component Manager		<th>Component Manager
	<th>~~Cross-module function~~ calls		<th>Function calls across components

	<tr>		<tr>
Line 23:		Line 23:
	<td rowspan="4">Events accepted		<td rowspan="4">Events accepted
	<td rowspan="5">All calls allowed		<td rowspan="5">All calls allowed
	<td rowspan="7">Calls across ~~modules~~ allowed		<td rowspan="7">Calls across components allowed

	<tr>		<tr>
Line 54:		Line 54:
	<th><tt>xpcom-loader-shutdown</tt> notification		<th><tt>xpcom-loader-shutdown</tt> notification
	<td>Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules.		<td>Component loaders (except for the binary/static component loaders) should do their final shutdown/cleanup activities, unloading all modules.
	<td rowspan="2">~~Cross-module function~~ calls not allowed		<td rowspan="2">Function calls across components not allowed

	<tr>		<tr>