Bug 1301313 - Bonus: Fix list formatting in AsyncShutdown documentation. r=dexter
authorGeorg Fritzsche <georg.fritzsche@googlemail.com>
Fri, 09 Sep 2016 00:43:25 +0700
changeset 354585 ef963f64fe0ee37d3ad19ccef88b8b4fe549e694
parent 354504 41ebaec6d7a7781e29678bd82b90dda6fc5473a5
child 354586 48d6981fbef25b2c0ff0e66a3d3be2aa8c81fb1b
push id6570
push userraliiev@mozilla.com
push dateMon, 14 Nov 2016 12:26:13 +0000
treeherdermozilla-beta@f455459b2ae5 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdexter
bugs1301313
milestone51.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1301313 - Bonus: Fix list formatting in AsyncShutdown documentation. r=dexter
toolkit/modules/docs/AsyncShutdown.rst
--- a/toolkit/modules/docs/AsyncShutdown.rst
+++ b/toolkit/modules/docs/AsyncShutdown.rst
@@ -1,43 +1,47 @@
 .. _AsyncShutdown:
 
 ==============
 AsyncShutdown
 ==============
 
 During shutdown of the process, subsystems are closed one after another. ``AsyncShutdown`` is a module dedicated to express shutdown-time dependencies between:
+
 - services and their clients;
 - shutdown phases (e.g. profile-before-change) and their clients.
 
 .. _AsyncShutdown_Barriers:
 
 Barriers: Expressing shutdown dependencies towards a service
 ============================================================
 
 Consider a service FooService. At some point during the shutdown of the process, this service needs to:
+
 - inform its clients that it is about to shut down;
 - wait until the clients have completed their final operations based on FooService (often asynchronously);
 - only then shut itself down.
 
 This may be expressed as an instance of ``AsyncShutdown.Barrier``. An instance of ``AsyncShutdown.Barrier`` provides:
+
 - a capability ``client`` that may be published to clients, to let them register or unregister blockers;
 - methods for the owner of the barrier to let it consult the state of blockers and wait until all client-registered blockers have been resolved.
 
 Shutdown timeouts
 -----------------
 
 By design, an instance of ``AsyncShutdown.Barrier`` will cause a crash
 if it takes more than 60 seconds `awake` for its clients to lift or
 remove their blockers (`awake` meaning that seconds during which the
 computer is asleep or too busy to do anything are not counted). This
 mechanism helps ensure that we do not leave the process in a state in
 which it can neither proceed with shutdown nor be relaunched.
 
 If the CrashReporter is enabled, this crash will report:
+
 - the name of the barrier that failed;
 - for each blocker that has not been released yet:
 
   - the name of the blocker;
   - the state of the blocker, if a state function has been provided (see :ref:`AsyncShutdown.Barrier.state`).
 
 Example 1: Simple Barrier client
 --------------------------------
@@ -214,16 +218,17 @@ Example 4: A service with both internal 
     });
 
 .. _AsyncShutdown_phases:
 
 Phases: Expressing dependencies towards phases of shutdown
 ==========================================================
 
 The shutdown of a process takes place by phase, such as:
+
 - ``profileBeforeChange`` (once this phase is complete, there is no guarantee that the process has access to a profile directory);
 - ``webWorkersShutdown`` (once this phase is complete, JavaScript does not have access to workers anymore);
 - ...
 
 Much as services, phases have clients. For instance, all users of web workers MUST have finished using their web workers before the end of phase ``webWorkersShutdown``.
 
 Module ``AsyncShutdown`` provides pre-defined barriers for a set of
 well-known phases. Each of the barriers provided blocks the corresponding shutdown