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"
|
|
|
|
|
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;
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
bool IsRunningTimeout() const { return mTimeoutFiringDepth > 0; }
|
|
|
|
|
|
|
|
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.
|
|
|
|
void RunTimeout(mozilla::dom::Timeout* aTimeout);
|
|
|
|
// Return true if |aTimeout| needs to be reinserted into the timeout list.
|
|
|
|
bool RescheduleTimeout(mozilla::dom::Timeout* aTimeout, const TimeStamp& now,
|
|
|
|
bool aRunningPendingTimeouts);
|
|
|
|
|
|
|
|
void ClearAllTimeouts();
|
|
|
|
uint32_t GetTimeoutId(mozilla::dom::Timeout::Reason aReason);
|
|
|
|
|
|
|
|
// Apply back pressure to the window if the TabGroup ThrottledEventQueue
|
|
|
|
// exists and has too many runnables waiting to run. For example, increase
|
|
|
|
// the minimum timer delay, etc.
|
|
|
|
void MaybeApplyBackPressure();
|
|
|
|
|
|
|
|
// Check the current ThrottledEventQueue depth and update the back pressure
|
|
|
|
// state. If the queue has drained back pressure may be canceled.
|
|
|
|
void CancelOrUpdateBackPressure(nsGlobalWindow* aWindow);
|
|
|
|
|
|
|
|
// When timers are being throttled and we reduce the thottle delay we must
|
|
|
|
// reschedule. The amount of the old throttle delay must be provided in
|
|
|
|
// order to bound how many timers must be examined.
|
|
|
|
nsresult ResetTimersForThrottleReduction();
|
|
|
|
|
2016-12-22 06:40:10 +03:00
|
|
|
int32_t DOMMinTimeoutValue(bool aIsTracking) 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();
|
|
|
|
|
|
|
|
// 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
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
nsresult ResetTimersForThrottleReduction(int32_t aPreviousThrottleDelayMS);
|
|
|
|
|
|
|
|
private:
|
2016-12-13 18:23:03 +03:00
|
|
|
struct Timeouts {
|
|
|
|
Timeouts()
|
|
|
|
: mTimeoutInsertionPoint(nullptr)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-12-14 03:06:21 +03:00
|
|
|
// Insert aTimeout into the list, before all timeouts that would
|
|
|
|
// fire after it, but no earlier than mTimeoutInsertionPoint, if any.
|
|
|
|
enum class SortBy
|
|
|
|
{
|
|
|
|
TimeRemaining,
|
|
|
|
TimeWhen
|
|
|
|
};
|
|
|
|
void Insert(mozilla::dom::Timeout* aTimeout, SortBy aSortBy);
|
|
|
|
nsresult ResetTimersForThrottleReduction(int32_t aPreviousThrottleDelayMS,
|
2016-12-22 06:40:10 +03:00
|
|
|
const TimeoutManager& aTimeoutManager,
|
2016-12-14 03:06:21 +03:00
|
|
|
SortBy aSortBy,
|
2016-11-27 22:24:34 +03:00
|
|
|
nsIEventTarget* aQueue);
|
2016-12-14 03:06:21 +03:00
|
|
|
|
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(); }
|
|
|
|
|
|
|
|
void SetInsertionPoint(Timeout* aTimeout)
|
|
|
|
{
|
|
|
|
mTimeoutInsertionPoint = aTimeout;
|
|
|
|
}
|
|
|
|
Timeout* InsertionPoint()
|
|
|
|
{
|
|
|
|
return mTimeoutInsertionPoint;
|
|
|
|
}
|
|
|
|
|
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:
|
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
|
|
|
typedef mozilla::LinkedList<mozilla::dom::Timeout> TimeoutList;
|
|
|
|
|
2016-12-13 18:23:03 +03:00
|
|
|
// mTimeoutList is generally sorted by mWhen, unless mTimeoutInsertionPoint is
|
|
|
|
// non-null. In that case, the dummy timeout pointed to by
|
|
|
|
// mTimeoutInsertionPoint may have a later mWhen than some of the timeouts
|
|
|
|
// that come after it.
|
|
|
|
TimeoutList mTimeoutList;
|
|
|
|
// If mTimeoutInsertionPoint is non-null, insertions should happen after it.
|
|
|
|
// This is a dummy timeout at the moment; if that ever changes, the logic in
|
|
|
|
// ResetTimersForThrottleReduction needs to change.
|
|
|
|
mozilla::dom::Timeout* mTimeoutInsertionPoint;
|
|
|
|
};
|
|
|
|
|
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;
|
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;
|
|
|
|
uint32_t mTimeoutFiringDepth;
|
|
|
|
mozilla::dom::Timeout* mRunningTimeout;
|
|
|
|
|
|
|
|
// The current idle request callback timeout handle
|
|
|
|
uint32_t mIdleCallbackTimeoutCounter;
|
|
|
|
|
|
|
|
int32_t mBackPressureDelayMS;
|
|
|
|
|
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
|