2020-12-11 05:03:40 +03:00
|
|
|
/* -*- 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);
|
2020-12-11 05:03:40 +03:00
|
|
|
|
|
|
|
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);
|
2020-12-11 05:03:40 +03:00
|
|
|
void ReleaseLock();
|
|
|
|
|
|
|
|
mozilla::MultiInstLockHandle mLock = MULTI_INSTANCE_LOCK_HANDLE_ERROR;
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif // nsUpdateSyncManager_h__
|