gecko-dev/xpcom/base/AppShutdown.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

129 строки
3.5 KiB
C
Исходник Обычный вид История

Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef AppShutdown_h
#define AppShutdown_h
#include <type_traits>
#include "nsCOMPtr.h"
#include "nsISupportsBase.h"
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
#include "ShutdownPhase.h"
namespace mozilla {
enum class AppShutdownMode {
Normal,
Restart,
};
class AppShutdown {
public:
static ShutdownPhase GetCurrentShutdownPhase();
Bug 1726813: Ensure AppShutdown remains in sync with shutdown notifications in the parent process. r=xpcom-reviewers,nika,dom-worker-reviewers,asuth 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
2021-09-15 10:25:29 +03:00
static bool IsInOrBeyond(ShutdownPhase aPhase);
/**
* Returns the current exit code that the process will be terminated with.
*/
static int GetExitCode();
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
/**
* Save environment variables that we might need if the app initiates a
* restart later in its lifecycle.
*/
static void SaveEnvVarsForPotentialRestart();
/**
* Init the shutdown with the requested shutdown mode and exit code.
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
*/
static void Init(AppShutdownMode aMode, int aExitCode);
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
/**
* Confirm that we are in fact going to be shutting down.
*/
static void OnShutdownConfirmed();
/**
* If we've attempted to initiate a restart, this call will set up the
* necessary environment variables and launch the new process.
*/
static void MaybeDoRestart();
/**
* The _exit() call is not a safe way to terminate your own process on
* Windows, because _exit runs DLL detach callbacks which run static
* destructors for xul.dll.
*
* This method terminates the current process without those issues.
*
* Optionally a custom exit code can be supplied.
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
*/
static void DoImmediateExit(int aExitCode = 0);
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
/**
* True if the application is currently attempting to shut down in order to
* restart.
*/
static bool IsRestarting();
/**
* Wrapper for shutdown notifications that informs the terminator before
* we notify other observers. Calls MaybeFastShutdown.
*/
static void AdvanceShutdownPhase(
ShutdownPhase aPhase, const char16_t* aNotificationData = nullptr,
const nsCOMPtr<nsISupports>& aNotificationSubject =
nsCOMPtr<nsISupports>(nullptr));
/**
* XXX: Before tackling bug 1697745 we need the
* possibility to advance the phase without notification
* in the content process.
*/
static void AdvanceShutdownPhaseWithoutNotify(ShutdownPhase aPhase);
/**
Bug 1726813: Ensure AppShutdown remains in sync with shutdown notifications in the parent process. r=xpcom-reviewers,nika,dom-worker-reviewers,asuth 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
2021-09-15 10:25:29 +03:00
* Map shutdown phase to observer key
*/
static const char* GetObserverKey(ShutdownPhase aPhase);
Bug 1726813: Ensure AppShutdown remains in sync with shutdown notifications in the parent process. r=xpcom-reviewers,nika,dom-worker-reviewers,asuth 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
2021-09-15 10:25:29 +03:00
/**
* Map shutdown phase to readable name
*/
static const char* GetShutdownPhaseName(ShutdownPhase aPhase);
Bug 1726813: Ensure AppShutdown remains in sync with shutdown notifications in the parent process. r=xpcom-reviewers,nika,dom-worker-reviewers,asuth 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
2021-09-15 10:25:29 +03:00
/**
* Map observer topic key to shutdown phase
*/
static ShutdownPhase GetShutdownPhaseFromTopic(const char* aTopic);
#ifdef DEBUG
/**
* Check, if we are allowed to send a shutdown notification.
* Shutdown specific topics are only allowed during calls to
* AdvanceShutdownPhase itself.
*/
static bool IsNoOrLegalShutdownTopic(const char* aTopic);
#endif
private:
/**
* This will perform a fast shutdown via _exit(0) or similar if the user's
* prefs are configured to do so at this phase.
*/
static void MaybeFastShutdown(ShutdownPhase aPhase);
/**
* Internal helper function, uses MaybeFastShutdown.
*/
static void AdvanceShutdownPhaseInternal(
ShutdownPhase aPhase, bool doNotify, const char16_t* aNotificationData,
const nsCOMPtr<nsISupports>& aNotificationSubject);
Bug 1606880 - Implement fast shutdown prefs r=froydnj I originally had this as a few patches, but the work to fix test failures and get the whole thing into a complete working state quickly tangled them up. Apologies for that. To summarize what's going on here, however: - We introduce two prefs: shutdown.fastShutdownStage and shutdown.lateWriteChecksStage. The latter pref is set to 1, which will leave the existing late write checking behavior unchanged. However, we introduce this pref to make it simpler in the future to bump the late write checks window earlier in the shutdown cycle. - We introduce an AppShutdown class, which will house static methods and a small amount of state for unifying some shutdown logic. Most importantly, it will now manage the state for app initiated restarts, as well as the logic for performing a safe fast shutdown. - We refactored the existing restart code to call into the new AppShutdown file, so that if we are configured to actually perform a fast shutdown, we will be able to run the necessary restart logic immediately before doing so. Previously, the restart logic occurred later in the shutdown cycle than our late write checking, meaning if we were to simply exit the process at that point in time, we would never run the restart coe. - Lastly, we updated two locations which called TerminateProcess and/or _exit(0) to call into the AppShutdown method (DoFastShutdown). Differential Revision: https://phabricator.services.mozilla.com/D59196 --HG-- extra : moz-landing-system : lando
2020-01-29 15:29:43 +03:00
};
} // namespace mozilla
#endif // AppShutdown_h