gecko-dev/toolkit/xre/nsUpdateSyncManager.h

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

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

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim:set ts=2 sw=2 sts=2 et cindent: */
/* 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 nsUpdateSyncManager_h__
#define nsUpdateSyncManager_h__
#include "mozilla/AlreadyAddRefed.h"
#include "nsIObserver.h"
#include "nsIUpdateService.h"
#include "MultiInstanceLock.h"
// The update sync manager is responsible for making sure that only one
// instance of the application is running at the time we want to start updating
// it. It does this by taking a multi-instance lock very early during the
// application's startup process. Then, when app update tasks are ready to run,
// the update service asks us whether anything else has also taken that lock,
// which, if true, would mean another instance of the application is currently
// running and performing update tasks should be avoided (the update service
// also runs a timeout and eventually goes ahead with the update in order to
// prevent an external program from effectively disabling updates).
class nsUpdateSyncManager final : public nsIUpdateSyncManager,
public nsIObserver {
public:
Bug 1695797 - In background task mode, only process updates if we're the sole instance running. r=mhowell,application-update-reviewers,dthayer,bytesized This commit does three main things: 1) It allows to configure the global singleton `nsUpdateSyncManager` with an `nsIFile` rather than having it use the ambient XPCOM directory service. This allows to initialize the `nsUpdateSyncManager` very early: before processing updates and long before XPCOM is initialized. This in turn allows us to determine if other instances early enough to skip processing updates when appropriate. When this initialization path is followed, i.e., in Firefox but not `xpcshell`, the `xpcom-startup` notification will be received but no action taken, since the singleton will already exist. There is a classic time-of-check, time-of-use race window in this implementation: an instance may be launched immediately after we check for other instances. In practice this will result in behaviour that is alreay possible: two independent instances both processing updates. It is expected that the updater itself will exclude one of the instances using its existing mutex. 2) It updates an existing background task test to use an explicit `nsIFile` rather than the existing directory service method. This exercises the newer API. There are other tests that might benefit, but there's no harm in remaining with the previous approach, since both are required. 3) It adds a new background task test to verify that update processing is skipped if we're not the sole instance running. Differential Revision: https://phabricator.services.mozilla.com/D106994
2021-03-06 08:40:39 +03:00
explicit nsUpdateSyncManager(nsIFile* anAppFile = nullptr);
NS_DECL_THREADSAFE_ISUPPORTS
NS_DECL_NSIUPDATESYNCMANAGER
NS_DECL_NSIOBSERVER
static already_AddRefed<nsUpdateSyncManager> GetSingleton();
private:
~nsUpdateSyncManager();
nsUpdateSyncManager(nsUpdateSyncManager&) = delete;
nsUpdateSyncManager(nsUpdateSyncManager&&) = delete;
nsUpdateSyncManager& operator=(nsUpdateSyncManager&) = delete;
nsUpdateSyncManager& operator=(nsUpdateSyncManager&&) = delete;
Bug 1695797 - In background task mode, only process updates if we're the sole instance running. r=mhowell,application-update-reviewers,dthayer,bytesized This commit does three main things: 1) It allows to configure the global singleton `nsUpdateSyncManager` with an `nsIFile` rather than having it use the ambient XPCOM directory service. This allows to initialize the `nsUpdateSyncManager` very early: before processing updates and long before XPCOM is initialized. This in turn allows us to determine if other instances early enough to skip processing updates when appropriate. When this initialization path is followed, i.e., in Firefox but not `xpcshell`, the `xpcom-startup` notification will be received but no action taken, since the singleton will already exist. There is a classic time-of-check, time-of-use race window in this implementation: an instance may be launched immediately after we check for other instances. In practice this will result in behaviour that is alreay possible: two independent instances both processing updates. It is expected that the updater itself will exclude one of the instances using its existing mutex. 2) It updates an existing background task test to use an explicit `nsIFile` rather than the existing directory service method. This exercises the newer API. There are other tests that might benefit, but there's no harm in remaining with the previous approach, since both are required. 3) It adds a new background task test to verify that update processing is skipped if we're not the sole instance running. Differential Revision: https://phabricator.services.mozilla.com/D106994
2021-03-06 08:40:39 +03:00
nsresult OpenLock(nsIFile* anAppFile = nullptr);
void ReleaseLock();
mozilla::MultiInstLockHandle mLock = MULTI_INSTANCE_LOCK_HANDLE_ERROR;
};
#endif // nsUpdateSyncManager_h__