2016-12-03 01:22:48 +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 mozilla_dom_TimeoutManager_h__
|
|
|
|
#define mozilla_dom_TimeoutManager_h__
|
|
|
|
|
|
|
|
#include "mozilla/dom/Timeout.h"
|
2017-05-19 23:45:55 +03:00
|
|
|
#include "nsTArray.h"
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2016-11-27 22:24:34 +03:00
|
|
|
class nsIEventTarget;
|
2016-12-03 01:22:48 +03:00
|
|
|
class nsITimeoutHandler;
|
|
|
|
class nsGlobalWindow;
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
class OrderedTimeoutIterator;
|
2017-06-01 03:13:19 +03:00
|
|
|
class TimeoutExecutor;
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// This class manages the timeouts in a Window's setTimeout/setInterval pool.
|
|
|
|
class TimeoutManager final
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
explicit TimeoutManager(nsGlobalWindow& aWindow);
|
2017-01-10 06:16:31 +03:00
|
|
|
~TimeoutManager();
|
2016-12-03 01:22:48 +03:00
|
|
|
TimeoutManager(const TimeoutManager& rhs) = delete;
|
|
|
|
void operator=(const TimeoutManager& rhs) = delete;
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
bool IsRunningTimeout() const;
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
static uint32_t GetNestingLevel() { return sNestingLevel; }
|
|
|
|
static void SetNestingLevel(uint32_t aLevel) { sNestingLevel = aLevel; }
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
bool HasTimeouts() const
|
|
|
|
{
|
|
|
|
return !mNormalTimeouts.IsEmpty() ||
|
|
|
|
!mTrackingTimeouts.IsEmpty();
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
nsresult SetTimeout(nsITimeoutHandler* aHandler,
|
|
|
|
int32_t interval, bool aIsInterval,
|
|
|
|
mozilla::dom::Timeout::Reason aReason,
|
|
|
|
int32_t* aReturn);
|
|
|
|
void ClearTimeout(int32_t aTimerId,
|
|
|
|
mozilla::dom::Timeout::Reason aReason);
|
|
|
|
|
|
|
|
// The timeout implementation functions.
|
2017-06-01 03:13:19 +03:00
|
|
|
void RunTimeout(const TimeStamp& aNow, const TimeStamp& aTargetDeadline);
|
2016-12-03 01:22:48 +03:00
|
|
|
// Return true if |aTimeout| needs to be reinserted into the timeout list.
|
2017-06-01 03:13:18 +03:00
|
|
|
bool RescheduleTimeout(mozilla::dom::Timeout* aTimeout, const TimeStamp& now);
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
void ClearAllTimeouts();
|
|
|
|
uint32_t GetTimeoutId(mozilla::dom::Timeout::Reason aReason);
|
|
|
|
|
2017-06-16 03:30:48 +03:00
|
|
|
TimeDuration CalculateDelay(Timeout* aTimeout) const;
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// aTimeout is the timeout that we're about to start running. This function
|
|
|
|
// returns the current timeout.
|
|
|
|
mozilla::dom::Timeout* BeginRunningTimeout(mozilla::dom::Timeout* aTimeout);
|
|
|
|
// aTimeout is the last running timeout.
|
|
|
|
void EndRunningTimeout(mozilla::dom::Timeout* aTimeout);
|
|
|
|
|
|
|
|
void UnmarkGrayTimers();
|
|
|
|
|
|
|
|
// These four methods are intended to be called from the corresponding methods
|
|
|
|
// on nsGlobalWindow.
|
|
|
|
void Suspend();
|
|
|
|
void Resume();
|
|
|
|
void Freeze();
|
|
|
|
void Thaw();
|
|
|
|
|
2017-06-14 04:08:27 +03:00
|
|
|
// This should be called by nsGlobalWindow when the window might have moved
|
|
|
|
// to the background or foreground.
|
|
|
|
void UpdateBackgroundState();
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// Initialize TimeoutManager before the first time it is accessed.
|
|
|
|
static void Initialize();
|
|
|
|
|
2016-12-01 03:32:23 +03:00
|
|
|
// Exposed only for testing
|
|
|
|
bool IsTimeoutTracking(uint32_t aTimeoutId);
|
|
|
|
|
2017-02-13 23:58:39 +03:00
|
|
|
// The document finished loading
|
|
|
|
void OnDocumentLoaded();
|
|
|
|
void StartThrottlingTrackingTimeouts();
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
// Run some code for each Timeout in our list. Note that this function
|
|
|
|
// doesn't guarantee that Timeouts are iterated in any particular order.
|
2016-12-03 01:22:48 +03:00
|
|
|
template <class Callable>
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
void ForEachUnorderedTimeout(Callable c)
|
2016-12-03 01:22:48 +03:00
|
|
|
{
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
mNormalTimeouts.ForEach(c);
|
|
|
|
mTrackingTimeouts.ForEach(c);
|
2016-12-14 02:14:02 +03:00
|
|
|
}
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
// Run some code for each Timeout in our list, but let the callback cancel the
|
|
|
|
// iteration by returning true. Note that this function doesn't guarantee
|
|
|
|
// that Timeouts are iterated in any particular order.
|
2016-12-14 02:14:02 +03:00
|
|
|
template <class Callable>
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
void ForEachUnorderedTimeoutAbortable(Callable c)
|
2016-12-14 02:14:02 +03:00
|
|
|
{
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
if (!mNormalTimeouts.ForEachAbortable(c)) {
|
|
|
|
mTrackingTimeouts.ForEachAbortable(c);
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2017-05-02 14:23:00 +03:00
|
|
|
void BeginSyncOperation();
|
|
|
|
void EndSyncOperation();
|
2017-05-19 23:45:55 +03:00
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
nsIEventTarget*
|
|
|
|
EventTarget();
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
static const uint32_t InvalidFiringId;
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
private:
|
2017-04-25 12:20:00 +03:00
|
|
|
void MaybeStartThrottleTrackingTimout();
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-05-02 14:23:00 +03:00
|
|
|
bool IsBackground() const;
|
2017-05-19 23:45:55 +03:00
|
|
|
|
|
|
|
uint32_t
|
|
|
|
CreateFiringId();
|
|
|
|
|
|
|
|
void
|
|
|
|
DestroyFiringId(uint32_t aFiringId);
|
|
|
|
|
2017-06-05 22:42:33 +03:00
|
|
|
bool
|
|
|
|
IsValidFiringId(uint32_t aFiringId) const;
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
bool
|
|
|
|
IsInvalidFiringId(uint32_t aFiringId) const;
|
|
|
|
|
2017-06-14 04:08:27 +03:00
|
|
|
TimeDuration
|
|
|
|
MinSchedulingDelay() const;
|
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
void RecordExecution(mozilla::dom::Timeout* aRunningTimeout,
|
|
|
|
mozilla::dom::Timeout* aTimeout);
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
private:
|
2016-12-13 18:23:03 +03:00
|
|
|
struct Timeouts {
|
2017-06-05 22:42:33 +03:00
|
|
|
explicit Timeouts(const TimeoutManager& aManager)
|
|
|
|
: mManager(aManager)
|
2016-12-13 18:23:03 +03:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-12-14 03:06:21 +03:00
|
|
|
// Insert aTimeout into the list, before all timeouts that would
|
2017-06-05 22:42:33 +03:00
|
|
|
// fire after it, but no earlier than the last Timeout with a
|
|
|
|
// valid FiringId.
|
2016-12-14 03:06:21 +03:00
|
|
|
enum class SortBy
|
|
|
|
{
|
|
|
|
TimeRemaining,
|
|
|
|
TimeWhen
|
|
|
|
};
|
|
|
|
void Insert(mozilla::dom::Timeout* aTimeout, SortBy aSortBy);
|
|
|
|
|
2016-12-13 18:23:03 +03:00
|
|
|
const Timeout* GetFirst() const { return mTimeoutList.getFirst(); }
|
|
|
|
Timeout* GetFirst() { return mTimeoutList.getFirst(); }
|
|
|
|
const Timeout* GetLast() const { return mTimeoutList.getLast(); }
|
|
|
|
Timeout* GetLast() { return mTimeoutList.getLast(); }
|
|
|
|
bool IsEmpty() const { return mTimeoutList.isEmpty(); }
|
|
|
|
void InsertFront(Timeout* aTimeout) { mTimeoutList.insertFront(aTimeout); }
|
|
|
|
void Clear() { mTimeoutList.clear(); }
|
|
|
|
|
2016-12-14 02:14:02 +03:00
|
|
|
template <class Callable>
|
|
|
|
void ForEach(Callable c)
|
|
|
|
{
|
|
|
|
for (Timeout* timeout = GetFirst();
|
|
|
|
timeout;
|
|
|
|
timeout = timeout->getNext()) {
|
|
|
|
c(timeout);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
// Returns true when a callback aborts iteration.
|
2016-12-14 02:14:02 +03:00
|
|
|
template <class Callable>
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
bool ForEachAbortable(Callable c)
|
2016-12-14 02:14:02 +03:00
|
|
|
{
|
|
|
|
for (Timeout* timeout = GetFirst();
|
|
|
|
timeout;
|
|
|
|
timeout = timeout->getNext()) {
|
|
|
|
if (c(timeout)) {
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
return true;
|
2016-12-14 02:14:02 +03:00
|
|
|
}
|
|
|
|
}
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
return false;
|
2016-12-14 02:14:02 +03:00
|
|
|
}
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
friend class OrderedTimeoutIterator;
|
|
|
|
|
2016-12-13 18:23:03 +03:00
|
|
|
private:
|
2017-06-05 22:42:33 +03:00
|
|
|
// The TimeoutManager that owns this Timeouts structure. This is
|
|
|
|
// mainly used to call state inspecting methods like IsValidFiringId().
|
|
|
|
const TimeoutManager& mManager;
|
|
|
|
|
2017-06-01 03:13:18 +03:00
|
|
|
typedef mozilla::LinkedList<RefPtr<Timeout>> TimeoutList;
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
|
2017-06-05 22:42:33 +03:00
|
|
|
// mTimeoutList is generally sorted by mWhen, but new values are always
|
|
|
|
// inserted after any Timeouts with a valid FiringId.
|
2016-12-13 18:23:03 +03:00
|
|
|
TimeoutList mTimeoutList;
|
|
|
|
};
|
|
|
|
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
friend class OrderedTimeoutIterator;
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// Each nsGlobalWindow object has a TimeoutManager member. This reference
|
|
|
|
// points to that holder object.
|
|
|
|
nsGlobalWindow& mWindow;
|
2017-06-01 03:13:19 +03:00
|
|
|
// The executor is specific to the nsGlobalWindow/TimeoutManager, but it
|
|
|
|
// can live past the destruction of the window if its scheduled. Therefore
|
|
|
|
// it must be a separate ref-counted object.
|
|
|
|
RefPtr<TimeoutExecutor> mExecutor;
|
Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
2016-12-16 00:17:38 +03:00
|
|
|
// The list of timeouts coming from non-tracking scripts.
|
|
|
|
Timeouts mNormalTimeouts;
|
|
|
|
// The list of timeouts coming from scripts on the tracking protection list.
|
|
|
|
Timeouts mTrackingTimeouts;
|
2016-12-03 01:22:48 +03:00
|
|
|
uint32_t mTimeoutIdCounter;
|
2017-05-19 23:45:55 +03:00
|
|
|
uint32_t mNextFiringId;
|
|
|
|
AutoTArray<uint32_t, 2> mFiringIdStack;
|
2016-12-03 01:22:48 +03:00
|
|
|
mozilla::dom::Timeout* mRunningTimeout;
|
|
|
|
|
|
|
|
// The current idle request callback timeout handle
|
|
|
|
uint32_t mIdleCallbackTimeoutCounter;
|
|
|
|
|
2017-02-13 23:58:39 +03:00
|
|
|
nsCOMPtr<nsITimer> mThrottleTrackingTimeoutsTimer;
|
|
|
|
bool mThrottleTrackingTimeouts;
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
static uint32_t sNestingLevel;
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|