| AbstractThread.cpp |
aIsTailDispatcher = |
12819 |
| AbstractThread.h |
We often want to run tasks on a target that guarantees that events will never
run in parallel. There are various target types that achieve this - namely
nsIThread and TaskQueue. Note that nsIThreadPool (which implements
nsIEventTarget) does not have this property, so we do not want to use
nsIEventTarget for this purpose. This class encapsulates the specifics of
the structures we might use here and provides a consistent interface.
At present, the supported AbstractThread implementations are TaskQueue,
AbstractThread::MainThread() and XPCOMThreadWrapper which can wrap any
nsThread.
The primary use of XPCOMThreadWrapper is to allow any threads to provide
Direct Task dispatching which is similar (but not identical to) the microtask
semantics of JS promises. Instantiating a XPCOMThreadWrapper on the current
nsThread is sufficient to enable direct task dispatching.
You shouldn't use pointers when comparing AbstractThread or nsIThread to
determine if you are currently on the thread, but instead use the
nsISerialEventTarget::IsOnCurrentThread() method.
|
5314 |
| BlockingResourceBase.cpp |
PrintCycle
Append to |aOut| detailed information about the circular
dependency in |aCycle|. Returns true if it *appears* that this
cycle may represent an imminent deadlock, but this is merely a
heuristic; the value returned may be a false positive or false
negative.
*NOT* thread safe. Calls |Print()|.
FIXME bug 456272 hack alert: because we can't write call
contexts into strings, all info is written to stderr, but only
some info is written into |aOut|
|
16507 |
| BlockingResourceBase.h |
BlockingResourceBase
Base class of resources that might block clients trying to acquire them.
Does debugging and deadlock detection in DEBUG builds.
|
8920 |
| components.conf |
|
1144 |
| CondVar.h |
Similarly to OffTheBooksMutex, OffTheBooksCondvar is identical to CondVar,
except that OffTheBooksCondVar doesn't include leak checking. Sometimes
you want to intentionally "leak" a CondVar until shutdown; in these cases,
OffTheBooksCondVar is for you.
|
3723 |
| CPUUsageWatcher.cpp |
|
7675 |
| CPUUsageWatcher.h |
|
3102 |
| DataMutex.h |
|
3796 |
| DeadlockDetector.h |
DeadlockDetector
The following is an approximate description of how the deadlock detector
works.
The deadlock detector ensures that all blocking resources are
acquired according to a partial order P. One type of blocking
resource is a lock. If a lock l1 is acquired (locked) before l2,
then we say that |l1 <_P l2|. The detector flags an error if two
locks l1 and l2 have an inconsistent ordering in P; that is, if
both |l1 <_P l2| and |l2 <_P l1|. This is a potential error
because a thread acquiring l1,l2 according to the first order might
race with a thread acquiring them according to the second order.
If this happens under the right conditions, then the acquisitions
will deadlock.
This deadlock detector doesn't know at compile-time what P is. So,
it tries to discover the order at run time. More precisely, it
finds <i>some</i> order P, then tries to find chains of resource
acquisitions that violate P. An example acquisition sequence, and
the orders they impose, is
l1.lock() // current chain: [ l1 ]
// order: { }
l2.lock() // current chain: [ l1, l2 ]
// order: { l1 <_P l2 }
l3.lock() // current chain: [ l1, l2, l3 ]
// order: { l1 <_P l2, l2 <_P l3, l1 <_P l3 }
// (note: <_P is transitive, so also |l1 <_P l3|)
l2.unlock() // current chain: [ l1, l3 ]
// order: { l1 <_P l2, l2 <_P l3, l1 <_P l3 }
// (note: it's OK, but weird, that l2 was unlocked out
// of order. we still have l1 <_P l3).
l2.lock() // current chain: [ l1, l3, l2 ]
// order: { l1 <_P l2, l2 <_P l3, l1 <_P l3,
l3 <_P l2 (!!!) }
BEEP BEEP! Here the detector will flag a potential error, since
l2 and l3 were used inconsistently (and potentially in ways that
would deadlock).
|
12287 |
| DelayedRunnable.cpp |
|
3027 |
| DelayedRunnable.h |
Called when the target is going away so the runnable can be released safely
on the target thread.
|
1467 |
| EventQueue.cpp |
|
5140 |
| EventQueue.h |
|
5230 |
| EventTargetCapability.h |
|
3456 |
| IdlePeriodState.cpp |
|
8883 |
| IdlePeriodState.h |
A class for tracking the state of our idle period. This includes keeping
track of both the state of our process-local idle period estimate and, for
content processes, managing communication with the parent process for
cross-pprocess idle detection.
|
7754 |
| IdleTaskRunner.cpp |
|
8512 |
| IdleTaskRunner.h |
|
4335 |
| InputTaskManager.cpp |
|
5066 |
| InputTaskManager.h |
|
4299 |
| LazyIdleThread.cpp |
nothing |
4016 |
| LazyIdleThread.h |
This class provides a basic event target that creates its thread lazily and
destroys its thread after a period of inactivity. It may be created and used
on any thread but it may only be shut down from the thread on which it is
created.
|
2897 |
| LeakRefPtr.h |
Smart pointer which leaks its owning refcounted object by default. |
1216 |
| MainThreadIdlePeriod.cpp |
static |
3001 |
| MainThreadIdlePeriod.h |
|
849 |
| MainThreadUtils.h |
Get a reference to the main thread.
@param aResult
The resulting nsIThread object.
|
1676 |
| Monitor.h |
Monitor provides a *non*-reentrant monitor: *not* a Java-style
monitor. If your code needs support for reentrancy, use
ReentrantMonitor instead. (Rarely should reentrancy be needed.)
Instead of directly calling Monitor methods, it's safer and simpler
to instead use the RAII wrappers MonitorAutoLock and
MonitorAutoUnlock.
|
9622 |
| moz.build |
|
3428 |
| MozPromise.h |
|
68989 |
| Mutex.h |
OffTheBooksMutex is identical to Mutex, except that OffTheBooksMutex doesn't
include leak checking. Sometimes you want to intentionally "leak" a mutex
until shutdown; in these cases, OffTheBooksMutex is for you.
|
14057 |
| nsEnvironment.cpp |
For Unix/Linux platforms we follow the Unix definition:
An environment variable exists when |getenv()| returns a non-nullptr
value. An environment variable does not exist when |getenv()| returns
nullptr.
|
3663 |
| nsEnvironment.h |
!nsEnvironment_h__ |
1092 |
| nsICancelableRunnable.h |
Cancels a pending task, so that calling run() on the task is a no-op.
Calling cancel after the task execution has begun will be a no-op.
Calling this method twice is considered an error.
@throws NS_ERROR_UNEXPECTED
Indicates that the runnable has already been canceled.
|
1389 |
| nsIDirectTaskDispatcher.idl |
The primary use of this interface is to allow any nsISerialEventTarget to
provide Direct Task dispatching which is similar (but not identical to) the
microtask semantics of JS promises.
New direct task may be dispatched when a current direct task is running. In
which case they will be run in FIFO order.
|
1686 |
| nsIDiscardableRunnable.h |
An interface implemented by nsIRunnable tasks for which nsIRunnable::Run()
might not be called.
|
1371 |
| nsIEnvironment.idl |
Scriptable access to the current process environment.
|
2117 |
| nsIEventTarget.idl |
until we can get rid of all uses, keep the non-alreadyAddRefed<> version |
9351 |
| nsIIdlePeriod.idl |
An instance implementing nsIIdlePeriod is used by an associated
nsIThread to estimate when it is likely that it will receive an
event.
|
986 |
| nsIIdleRunnable.h |
A task interface for tasks that can schedule their work to happen
in increments bounded by a deadline.
|
1527 |
| nsINamed.idl |
Represents an object with a name, such as a runnable or a timer.
|
881 |
| nsIProcess.idl |
Initialises the process with an executable to be run. Call the run method
to run the executable.
@param executable The executable to run.
|
4286 |
| nsIRunnable.idl |
Represents a task which can be dispatched to a thread for execution.
|
1533 |
| nsISerialEventTarget.idl |
A serial event target is an event dispatching interface like
nsIEventTarget. Runnables dispatched to an nsISerialEventTarget are required
to execute serially. That is, two different runnables dispatched to the
target should never be allowed to execute simultaneously. One exception to
this rule is nested event loops. If a runnable spins a nested event loop,
causing another runnable dispatched to the target to run, the target may
still be considered "serial".
Examples:
- nsIThread is a serial event target.
- Thread pools are not serial event targets.
- However, one can "convert" a thread pool into an nsISerialEventTarget
by putting a TaskQueue in front of it.
|
1209 |
| nsISupportsPriority.idl |
This interface exposes the general notion of a scheduled object with a
integral priority value. Following UNIX conventions, smaller (and possibly
negative) values have higher priority.
This interface does not strictly define what happens when the priority of an
object is changed. An implementation of this interface is free to define
the side-effects of changing the priority of an object. In some cases,
changing the priority of an object may be disallowed (resulting in an
exception being thrown) or may simply be ignored.
|
1750 |
| nsITargetShutdownTask.h |
|
1343 |
| nsIThread.idl |
This interface provides a high-level abstraction for an operating system
thread.
Threads have a built-in event queue, and a thread is an event target that
can receive nsIRunnable objects (events) to be processed on the thread.
See nsIThreadManager for the API used to create and locate threads.
|
8401 |
| nsIThreadInternal.idl |
The XPCOM thread object implements this interface, which allows a consumer
to observe dispatch activity on the thread.
|
4182 |
| nsIThreadManager.idl |
Returns true if the current nested event loop should stop spinning.
|
6502 |
| nsIThreadPool.idl |
Called when a new thread is created by the thread pool. The notification
happens on the newly-created thread.
|
4655 |
| nsIThreadShutdown.idl |
Handle for the ongoing shutdown progress of a given thread which can be used
to observe and interrupt async shutdown progress. Methods on this interface
may generally only be used on the thread which called
`nsIThread::beginShutdown`.
|
2211 |
| nsITimer.idl |
The signature of the timer callback function passed to initWithFuncCallback.
This is the function that will get called when the timer expires if the
timer is initialized via initWithFuncCallback.
@param aTimer the timer which has expired
@param aClosure opaque parameter passed to initWithFuncCallback
|
14627 |
| nsMemoryPressure.cpp |
A new memory pressure event erases an ongoing (or stop of) memory pressure,
but an existing "new" memory pressure event takes precedence over a new
"ongoing" or "stop" memory pressure event.
|
3686 |
| nsMemoryPressure.h |
These pre-defined strings are the topic to pass to the observer
service to declare the memory-pressure or lift the memory-pressure.
1. Notify kTopicMemoryPressure with kSubTopicLowMemoryNew
New memory pressure deteced
On a new memory pressure, we stop everything to start cleaning
aggresively the memory used, in order to free as much memory as
possible.
2. Notify kTopicMemoryPressure with kSubTopicLowMemoryOngoing
Repeated memory pressure.
A repeated memory pressure implies to clean softly recent allocations.
It is supposed to happen after a new memory pressure which already
cleaned aggressivley. So there is no need to damage the reactivity of
Gecko by stopping the world again.
In case of conflict with an new memory pressue, the new memory pressure
takes precedence over an ongoing memory pressure. The reason being
that if no events are processed between 2 notifications (new followed
by ongoing, or ongoing followed by a new) we want to be as aggresive as
possible on the clean-up of the memory. After all, we are trying to
keep Gecko alive as long as possible.
3. Notify kTopicMemoryPressureStop with nullptr
Memory pressure stopped.
We're no longer under acute memory pressure, so we might want to have a
chance of (cautiously) re-enabling some things we previously turned off.
As above, an already enqueued new memory pressure event takes precedence.
The priority ordering between concurrent attempts to queue both stopped
and ongoing memory pressure is currently not defined.
|
3271 |
| nsProcess.h |
|
2443 |
| nsProcessCommon.cpp |
nsProcess is used to execute new processes and specify if you want to
wait (blocking) or continue (non-blocking).
****************************************************************************
|
16027 |
| nsProxyRelease.cpp |
static |
1084 |
| nsProxyRelease.h |
Ensures that the delete of a smart pointer occurs on the target thread.
Note: The doomed object will be leaked if dispatch to the target thread
fails, as releasing it on the current thread may be unsafe
@param aName
the labelling name of the runnable involved in the releasing.
@param aTarget
the target thread where the doomed object should be released.
@param aDoomed
the doomed object; the object to be released on the target thread.
@param aAlwaysProxy
normally, if NS_ProxyRelease is called on the target thread, then the
doomed object will be released directly. However, if this parameter is
true, then an event will always be posted to the target thread for
asynchronous release.
@return result of the task which is dispatched to delete the smart pointer
on the target thread.
Note: The caller should not attempt to recover from an
error code returned by trying to perform the final ->Release()
manually.
|
13368 |
| nsThread.cpp |
|
47463 |
| nsThread.h |
|
12019 |
| nsThreadManager.cpp |
|
27109 |
| nsThreadManager.h |
|
5462 |
| nsThreadPool.cpp |
|
24082 |
| nsThreadPool.h |
547ec2a8-315e-4ec4-888e-6e4264fe90eb |
2727 |
| nsThreadSyncDispatch.h |
|
2133 |
| nsThreadUtils.cpp |
|
24137 |
| nsThreadUtils.h |
Create a new thread, and optionally provide an initial event for the thread.
@param aName
The name of the thread.
@param aResult
The resulting nsIThread object.
@param aInitialEvent
The initial event to run on this thread. This parameter may be null.
@param aOptions
Options used to configure thread creation.
Options are documented in nsIThreadManager.idl.
@returns NS_ERROR_INVALID_ARG
Indicates that the given name is not unique.
|
65034 |
| nsTimerImpl.cpp |
|
27433 |
| nsTimerImpl.h |
5ff24248-1dd2-11b2-8427-fbab44f29bc8 |
8332 |
| Queue.h |
|
7926 |
| RecursiveMutex.cpp |
|
2412 |
| RecursiveMutex.h |
AssertCurrentThreadIn
|
3490 |
| ReentrantMonitor.h |
ReentrantMonitor
Java-like monitor.
When possible, use ReentrantMonitorAutoEnter to hold this monitor within a
scope, instead of calling Enter/Exit directly.
|
7097 |
| RWLock.cpp |
|
681 |
| RWLock.h |
|
8219 |
| SchedulerGroup.cpp |
static |
679 |
| SchedulerGroup.h |
|
711 |
| SharedThreadPool.cpp |
static |
7439 |
| SharedThreadPool.h |
|
4999 |
| SpinEventLoopUntil.h |
|
7467 |
| StateMirroring.h |
The state-mirroring machinery allows pieces of interesting state to be
observed on multiple thread without locking. The basic strategy is to track
changes in a canonical value and post updates to other threads that hold
mirrors for that value.
One problem with the naive implementation of such a system is that some
pieces of state need to be updated atomically, and certain other operations
need to wait for these atomic updates to complete before executing. The
state-mirroring machinery solves this problem by requiring that its owner
thread uses tail dispatch, and posting state update events (which should
always be run first by TaskDispatcher implementations) to that tail
dispatcher. This ensures that state changes are always atomic from the
perspective of observing threads.
Given that state-mirroring is an automatic background process, we try to
avoid burdening the caller with worrying too much about teardown. To that
end, we don't assert dispatch success for any of the notifications, and
assume that any canonical or mirror owned by a thread for whom dispatch fails
will soon be disconnected by its holder anyway.
Given that semantics may change and comments tend to go out of date, we
deliberately don't provide usage examples here. Grep around to find them.
|
15952 |
| StateWatching.h |
The state-watching machinery automates the process of responding to changes
in various pieces of state.
A standard programming pattern is as follows:
mFoo = ...;
NotifyStuffChanged();
...
mBar = ...;
NotifyStuffChanged();
This pattern is error-prone and difficult to audit because it requires the
programmer to manually trigger the update routine. This can be especially
problematic when the update routine depends on numerous pieces of state, and
when that state is modified across a variety of helper methods. In these
cases the responsibility for invoking the routine is often unclear, causing
developers to scatter calls to it like pixie dust. This can result in
duplicate invocations (which is wasteful) and missing invocations in corner-
cases (which is a source of bugs).
This file provides a set of primitives that automatically handle updates and
allow the programmers to explicitly construct a graph of state dependencies.
When used correctly, it eliminates the guess-work and wasted cycles described
above.
There are two basic pieces:
(1) Objects that can be watched for updates. These inherit WatchTarget.
(2) Objects that receive objects and trigger processing. These inherit
AbstractWatcher. In the current machinery, these exist only internally
within the WatchManager, though that could change.
Note that none of this machinery is thread-safe - it must all happen on the
same owning thread. To solve multi-threaded use-cases, use state mirroring
and watch the mirrored value.
Given that semantics may change and comments tend to go out of date, we
deliberately don't provide usage examples here. Grep around to find them.
|
10457 |
| StaticString.h |
TODO(C++20): convert `constexpr` to `consteval` wherever possible. |
4199 |
| SynchronizedEventQueue.cpp |
|
907 |
| SynchronizedEventQueue.h |
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.
|
5448 |
| SyncRunnable.h |
This class will wrap a nsIRunnable and dispatch it to the target thread
synchronously. This is different from
NS_DispatchAndSpinEventLoopUntilComplete: this class does not spin the event
loop waiting for the event to be dispatched. This means that you don't risk
reentrance from pending messages, but you must be sure that the target thread
does not ever block on this thread, or else you will deadlock.
Typical usage:
RefPtr<SyncRunnable> sr = new SyncRunnable(new myrunnable...());
sr->DispatchToThread(t);
We also provide convenience wrappers:
SyncRunnable::DispatchToThread(pThread, new myrunnable...());
SyncRunnable::DispatchToThread(pThread, NS_NewRunnableFunction(...));
|
5285 |
| TaskController.cpp |
static |
40295 |
| TaskController.h |
|
17170 |
| TaskDispatcher.h |
A classic approach to cross-thread communication is to dispatch asynchronous
runnables to perform updates on other threads. This generally works well, but
there are sometimes reasons why we might want to delay the actual dispatch of
these tasks until a specified moment. At present, this is primarily useful to
ensure that mirrored state gets updated atomically - but there may be other
applications as well.
TaskDispatcher is a general abstract class that accepts tasks and dispatches
them at some later point. These groups of tasks are per-target-thread, and
contain separate queues for several kinds of tasks (see comments below). -
"state change tasks" (which run first, and are intended to be used to update
the value held by mirrors), and regular tasks, which are other arbitrary
operations that the are gated to run after all the state changes have
completed.
|
10499 |
| TaskQueue.cpp |
|
11218 |
| TaskQueue.h |
passed by ref |
10026 |
| ThreadBound.h |
|
4528 |
| ThreadDelay.cpp |
|
1191 |
| ThreadDelay.h |
|
670 |
| ThreadEventQueue.cpp |
|
10164 |
| ThreadEventQueue.h |
|
3175 |
| ThreadEventTarget.cpp |
|
4560 |
| ThreadEventTarget.h |
|
1895 |
| ThreadLocalVariables.cpp |
|
547 |
| ThrottledEventQueue.cpp |
|
15167 |
| ThrottledEventQueue.h |
|
5204 |
| TimerThread.cpp |
|
55727 |
| TimerThread.h |
|
9559 |
| VsyncTaskManager.cpp |
|
711 |
| VsyncTaskManager.h |
|
838 |
| WinHandleWatcher.cpp |
|
10917 |
| WinHandleWatcher.h |
... |
3651 |