Snappy/AsyncShutdown: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 10: Line 10:


== Telemetry data must be saved asynchronously ==
== Telemetry data must be saved asynchronously ==
(TBD)
== Telemetry data must be collected after profile-before-change ==
(TBD)
(TBD)


Line 24: Line 27:


== Session Restore data must be fully written before we remove the profile ==
== Session Restore data must be fully written before we remove the profile ==
(TBD)
 
Session Restore collects data during shutdown and must have finished writing that data before we complete profile-before-change.
 
== FHR data must be fully written before we remove the profile ==
 
FHR closes its databases and must have finished writing that data before we complete profile-before-change.


= Related bugs =
= Related bugs =
- https://bugzilla.mozilla.org/show_bug.cgi?id=722648 - Asynchronous observers.
- https://bugzilla.mozilla.org/show_bug.cgi?id=722648 - Asynchronous observers.
- https://bugzilla.mozilla.org/show_bug.cgi?id=881667 - Expose startup/shutdown stage to components.
- https://bugzilla.mozilla.org/show_bug.cgi?id=881667 - Expose startup/shutdown stage to components.

Revision as of 12:22, 10 September 2013

Our objective

At the moment, Firefox shuts down mostly sequentially. Waiting until an asynchronous task is complete before proceeding with shutdown is complicated and requires spinning the event loop, which is generally Not a Good Idea.

We need to start thinking about a way to shutdown asynchronous services.

Use cases

Asynchronous databases need to be AsyncClosed()

(TBD)

Telemetry data must be saved asynchronously

(TBD)

Telemetry data must be collected after profile-before-change

(TBD)

Downloads API may have a pending "downloads.json" write

Before saving the list of in-progress downloads, the Downloads API waits 1.5 seconds after every change in state of downloads.

Being able to force an asynchronous write of the JSON file in case the browser is closed during the 1.5 seconds window might be useful.

OS.File data must be fully written before we remove the profile

Any call to OS.File.writeAtomic that is placed before the completion of profile-before-change must be completed before we actually remove the profile.

e.g. Bug 911820 for an example of actual dataloss.

Session Restore data must be fully written before we remove the profile

Session Restore collects data during shutdown and must have finished writing that data before we complete profile-before-change.

FHR data must be fully written before we remove the profile

FHR closes its databases and must have finished writing that data before we complete profile-before-change.

Related bugs

- https://bugzilla.mozilla.org/show_bug.cgi?id=722648 - Asynchronous observers. - https://bugzilla.mozilla.org/show_bug.cgi?id=881667 - Expose startup/shutdown stage to components.