Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +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_ThreadEventQueue_h
|
|
|
|
|
#define mozilla_ThreadEventQueue_h
|
|
|
|
|
|
|
|
|
|
#include "mozilla/AbstractEventQueue.h"
|
|
|
|
|
#include "mozilla/CondVar.h"
|
|
|
|
|
#include "mozilla/SynchronizedEventQueue.h"
|
|
|
|
|
#include "nsCOMPtr.h"
|
|
|
|
|
#include "nsTArray.h"
|
|
|
|
|
|
|
|
|
|
class nsIEventTarget;
|
|
|
|
|
class nsISerialEventTarget;
|
|
|
|
|
class nsIThreadObserver;
|
|
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
|
|
|
|
|
|
class EventQueue;
|
|
|
|
|
|
|
|
|
|
template<typename InnerQueueT>
|
|
|
|
|
class PrioritizedEventQueue;
|
|
|
|
|
|
2017-09-02 02:39:13 +03:00
|
|
|
class LabeledEventQueue;
|
|
|
|
|
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
class ThreadEventTarget;
|
|
|
|
|
|
|
|
|
|
// A ThreadEventQueue implements normal monitor-style synchronization over the
|
|
|
|
|
// InnerQueueT AbstractEventQueue. It also implements PushEventQueue and
|
|
|
|
|
// PopEventQueue for workers (see the documentation below for an explanation of
|
|
|
|
|
// those). All threads use a ThreadEventQueue as their event queue. InnerQueueT
|
|
|
|
|
// is a template parameter to avoid virtual dispatch overhead.
|
|
|
|
|
template<class InnerQueueT>
|
|
|
|
|
class ThreadEventQueue final : public SynchronizedEventQueue
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
explicit ThreadEventQueue(UniquePtr<InnerQueueT> aQueue);
|
|
|
|
|
|
|
|
|
|
bool PutEvent(already_AddRefed<nsIRunnable>&& aEvent,
|
2018-02-06 09:46:57 +03:00
|
|
|
EventPriority aPriority) final;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
|
|
|
|
already_AddRefed<nsIRunnable> GetEvent(bool aMayWait,
|
2018-02-06 09:46:57 +03:00
|
|
|
EventPriority* aPriority) final;
|
|
|
|
|
bool HasPendingEvent() final;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
2018-02-06 09:46:57 +03:00
|
|
|
bool ShutdownIfNoPendingEvents() final;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
2018-02-06 09:46:57 +03:00
|
|
|
void Disconnect(const MutexAutoLock& aProofOfLock) final {}
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
2018-02-06 09:46:57 +03:00
|
|
|
void EnableInputEventPrioritization() final;
|
|
|
|
|
void FlushInputEventPrioritization() final;
|
|
|
|
|
void SuspendInputEventPrioritization() final;
|
|
|
|
|
void ResumeInputEventPrioritization() final;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This method causes any events currently enqueued on the thread to be
|
|
|
|
|
* suppressed until PopEventQueue is called, and any event dispatched to this
|
|
|
|
|
* thread's nsIEventTarget will queue as well. Calls to PushEventQueue may be
|
|
|
|
|
* nested and must each be paired with a call to PopEventQueue in order to
|
|
|
|
|
* restore the original state of the thread. The returned nsIEventTarget may
|
|
|
|
|
* be used to push events onto the nested queue. Dispatching will be disabled
|
|
|
|
|
* once the event queue is popped. The thread will only ever process pending
|
|
|
|
|
* events for the innermost event queue. Must only be called on the target
|
|
|
|
|
* thread.
|
|
|
|
|
*/
|
|
|
|
|
already_AddRefed<nsISerialEventTarget> PushEventQueue();
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Revert a call to PushEventQueue. When an event queue is popped, any events
|
|
|
|
|
* remaining in the queue are appended to the elder queue. This also causes
|
|
|
|
|
* the nsIEventTarget returned from PushEventQueue to stop dispatching events.
|
|
|
|
|
* Must only be called on the target thread, and with the innermost event
|
|
|
|
|
* queue.
|
|
|
|
|
*/
|
|
|
|
|
void PopEventQueue(nsIEventTarget* aTarget);
|
|
|
|
|
|
2018-02-06 09:46:57 +03:00
|
|
|
already_AddRefed<nsIThreadObserver> GetObserver() final;
|
|
|
|
|
already_AddRefed<nsIThreadObserver> GetObserverOnThread() final;
|
|
|
|
|
void SetObserver(nsIThreadObserver* aObserver) final;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
|
|
|
|
Mutex& MutexRef() { return mLock; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
class NestedSink;
|
|
|
|
|
|
|
|
|
|
virtual ~ThreadEventQueue();
|
|
|
|
|
|
|
|
|
|
bool PutEventInternal(already_AddRefed<nsIRunnable>&& aEvent,
|
|
|
|
|
EventPriority aPriority,
|
|
|
|
|
NestedSink* aQueue);
|
|
|
|
|
|
|
|
|
|
UniquePtr<InnerQueueT> mBaseQueue;
|
|
|
|
|
|
|
|
|
|
struct NestedQueueItem
|
|
|
|
|
{
|
|
|
|
|
UniquePtr<EventQueue> mQueue;
|
|
|
|
|
RefPtr<ThreadEventTarget> mEventTarget;
|
|
|
|
|
|
|
|
|
|
NestedQueueItem(UniquePtr<EventQueue> aQueue,
|
|
|
|
|
ThreadEventTarget* aEventTarget)
|
2018-05-30 22:15:35 +03:00
|
|
|
: mQueue(std::move(aQueue))
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
, mEventTarget(aEventTarget)
|
|
|
|
|
{}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
nsTArray<NestedQueueItem> mNestedQueues;
|
|
|
|
|
|
|
|
|
|
Mutex mLock;
|
|
|
|
|
CondVar mEventsAvailable;
|
|
|
|
|
|
|
|
|
|
bool mEventsAreDoomed = false;
|
|
|
|
|
nsCOMPtr<nsIThreadObserver> mObserver;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern template class ThreadEventQueue<EventQueue>;
|
|
|
|
|
extern template class ThreadEventQueue<PrioritizedEventQueue<EventQueue>>;
|
2017-09-02 02:39:13 +03:00
|
|
|
extern template class ThreadEventQueue<PrioritizedEventQueue<LabeledEventQueue>>;
|
Bug 1382922 - Refactor event queue to allow multiple implementations (r=erahm)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
2017-06-21 05:42:13 +03:00
|
|
|
|
|
|
|
|
}; // namespace mozilla
|
|
|
|
|
|
|
|
|
|
#endif // mozilla_ThreadEventQueue_h
|
