mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-30 08:12:05 +00:00
b21e2d519a
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons. We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly. Some further notes: # The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe. # Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course. # However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972). # The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now. # This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745. # This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`. Differential Revision: https://phabricator.services.mozilla.com/D124350 |
||
|---|---|---|
| .. | ||
| bloatview | ||
| browsertime | ||
| clang-tidy | ||
| code-coverage | ||
| compare-locales | ||
| coverity | ||
| crashreporter | ||
| fuzzing | ||
| github-sync | ||
| infer | ||
| jprof | ||
| leak-gauge | ||
| lint | ||
| moztreedocs | ||
| performance | ||
| phabricator | ||
| power | ||
| profiler | ||
| quitter | ||
| rb | ||
| rewriting | ||
| rusttests | ||
| sanitizer/docs | ||
| tryselect | ||
| update-packaging | ||
| update-programs | ||
| update-verify | ||
| vcs | ||
| mach_commands.py | ||
| moz.build | ||