Name Description Size
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| 15116
BlockingResourceBase.h BlockingResourceBase Base class of resources that might block clients trying to acquire them. Does debugging and deadlock detection in DEBUG builds. 8873
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 4903
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 3943
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 3406
MozPromise.h 68920
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. 1683
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. 1526
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. 8465
nsIThreadInternal.idl The XPCOM thread object implements this interface, which allows a consumer to observe dispatch activity on the thread. 4205
nsIThreadManager.idl Returns true if the current nested event loop should stop spinning. 6485
nsIThreadPool.idl Called when a new thread is created by the thread pool. The notification happens on the newly-created thread. 4459
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 48757
nsThread.h 12165
nsThreadManager.cpp 26719
nsThreadManager.h 5462
nsThreadPool.cpp 19017
nsThreadPool.h 547ec2a8-315e-4ec4-888e-6e4264fe90eb 2356
nsThreadSyncDispatch.h 2133
nsThreadUtils.cpp 24077
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. 64915
nsTimerImpl.cpp 27432
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. 9992
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 36552
TaskController.h 16733
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 10980
TaskQueue.h passed by ref 10026
ThreadBound.h 4528
ThreadDelay.cpp 1191
ThreadDelay.h 670
ThreadEventQueue.cpp 10344
ThreadEventQueue.h 3175
ThreadEventTarget.cpp 4560
ThreadEventTarget.h 1895
ThreadLocalVariables.cpp 547
ThrottledEventQueue.cpp 15238
ThrottledEventQueue.h 5204
TimerThread.cpp 55739
TimerThread.h 9559
VsyncTaskManager.cpp 711
VsyncTaskManager.h 838
WinHandleWatcher.cpp 10917
WinHandleWatcher.h ... 3651