On 5/15/13 2:18 PM, Vladan Djeric wrote:
Hi all,
I recently came across a situation where it would have been useful to
control the order in which components receive the same shutdown
notification. Specifically, Telemetry writes out session data to the
profile dir during the "profile-before-change" event, but it needs to
include any measurements reported by other components while they are
handling the same "profile-before-change" notification. So ideally,
Telemetry would be the last observer to get the notification.
As an additional example, OS.File needs to be the second-last observer
of "profile-before-change", since it needs to service new requests to
OS.File from other components during their handling of
"profile-before-change", but it also needs to record measurements in
Telemetry before Telemetry has handled the same event.
I'd like to know if these use-cases are sufficiently rare that we should
just add new shutdown events when needed (e.g. we added
"profile-before-change2" for Telemetry in bug 844331), or if we should
come up with a general way to impose order of shutdown based on
dependencies?
There are race conditions all over the place. Another example is
preferences. Preferences flush during one of the shutdown observers
IIRC. If your observer mutates preferences after preferences has fired,
pref writes are lost. So, it all comes down to relying on the order
observers were registered on startup (since observers are notified in
registration order). This all seems rather fragile to me.
I think the more compelling use case is service startup. Proper
dependencies should allow us to more intelligently start services on
demand. This should lead to lower resource utilization and faster
startup times. Shutdown times should also speed up if there are fewer
services to shut down.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
