Name Description Size
AbstractEventQueue.h 3708
AbstractThread.cpp aIsTailDispatcher = 9176
AbstractThread.h NOTE: PLEASE AVOID USE OF AbstractThread OUTSIDE MEDIA CODE WHEN POSSIBLE. The nsISerialEventTarget interface should be preferred. AbstractThread has unusual "tail dispatch" semantics that usually are not needed outside of media code. 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 DocGroup::AbstractThreadFor(). If you add support for another thread that is not the MainThread, you'll need to figure out how to make it unique such that comparing AbstractThread pointers is equivalent to comparing nsIThread pointers. 5981
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| 15768
BlockingResourceBase.h BlockingResourceBase Base class of resources that might block clients trying to acquire them. Does debugging and deadlock detection in DEBUG builds. 8609
components.conf 853
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. 3538
CPUUsageWatcher.cpp 7782
CPUUsageWatcher.h 2891
DataMutex.h 2662
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). 12348
EventQueue.cpp 1569
EventQueue.h 2021
IdleTaskRunner.cpp 5717
IdleTaskRunner.h 2418
InputEventStatistics.cpp static 2456
InputEventStatistics.h 3248
LazyIdleThread.cpp nothing 15953
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 on any thread but it may only be used from the thread on which it is created. If it is created on the main thread then it will automatically join its thread on XPCOM shutdown using the Observer Service. 6457
LeakRefPtr.h Smart pointer which leaks its owning refcounted object by default. 1216
MainThreadIdlePeriod.cpp static 2215
MainThreadIdlePeriod.h 841
MainThreadQueue.h 1559
MainThreadUtils.h Get a reference to the main thread. @param aResult The resulting nsIThread object. 1221
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. 3426
moz.build 2778
MozPromise.h 55028
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. 6802
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. 3762
nsEnvironment.h !nsEnvironment_h__ 1159
nsICancelableRunnable.h Cancels a pending task. If the task has already been executed this 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. 1317
nsIEnvironment.idl Scriptable access to the current process environment. 2119
nsIEventTarget.idl until we can get rid of all uses, keep the non-alreadyAddRefed<> version 7104
nsIIdlePeriod.idl An instance implementing nsIIdlePeriod is used by an associated nsIThread to estimate when it is likely that it will receive an event. 1000
nsIIdleRunnable.h A task interface for tasks that can schedule their work to happen in increments bounded by a deadline. 1510
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. 4251
nsIRunnable.idl Represents a task which can be dispatched to a thread for execution. 927
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. 1198
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. 1752
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. 6886
nsIThreadInternal.idl The XPCOM thread object implements this interface, which allows a consumer to observe dispatch activity on the thread. 4196
nsIThreadManager.idl Returns true if the current nested event loop should stop spinning. 5335
nsIThreadPool.idl Called when a new thread is created by the thread pool. The notification happens on the newly-created thread. 4129
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 13118
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. 1679
nsMemoryPressure.h No memory pressure. 3037
nsProcess.h 2401
nsProcessCommon.cpp nsProcess is used to execute new processes and specify if you want to wait (blocking) or continue (non-blocking). **************************************************************************** 18019
nsProxyRelease.cpp static 1104
nsProxyRelease.h Ensures that the delete of a smart pointer occurs on the target thread. @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. 13537
nsThread.cpp 44169
nsThread.h 9651
nsThreadManager.cpp static 18420
nsThreadManager.h 7a4204c6-e45a-4c37-8ebb-6709a22c917c 3566
nsThreadPool.cpp 17420
nsThreadPool.h 547ec2a8-315e-4ec4-888e-6e4264fe90eb 1801
nsThreadSyncDispatch.h 1864
nsThreadUtils.cpp 18765
nsThreadUtils.h Create a new thread, and optionally provide an initial event for the thread. @param aResult The resulting nsIThread object. @param aInitialEvent The initial event to run on this thread. This parameter may be null. @param aStackSize The size in bytes to reserve for the thread's stack. @returns NS_ERROR_INVALID_ARG Indicates that the given name is not unique. 64718
nsTimerImpl.cpp 25583
nsTimerImpl.h 5ff24248-1dd2-11b2-8427-fbab44f29bc8 8462
PerformanceCounter.cpp 2377
PerformanceCounter.h The DispatchCategory class is used to fake the inheritance of the TaskCategory enum so we can extend it to hold one more value corresponding to the category we use when a worker dispatches a call. 4185
PrioritizedEventQueue.cpp 13138
PrioritizedEventQueue.h 6408
Queue.h How we count the number of events in the queue: 1. Let pageCount(x, y) denote the number of pages excluding the tail page where x is the index of head page and y is the index of the tail page. 2. Then we have pageCount(x, y) = y - x. Ex: pageCount(0, 0) = 0 where both head and tail pages point to page 0. pageCount(0, 1) = 1 where head points to page 0 and tail points page 1. 3. number of events = (ItemsPerPage * pageCount(x, y)) - (empty slots in head page) + (non-empty slots in tail page) = (ItemsPerPage * pageCount(x, y)) - mOffsetHead + mOffsetTail 5341
RecursiveMutex.cpp 2491
RecursiveMutex.h AssertCurrentThreadIn 3319
ReentrantMonitor.h ReentrantMonitor Java-like monitor. When possible, use ReentrantMonitorAutoEnter to hold this monitor within a scope, instead of calling Enter/Exit directly. 6636
RWLock.cpp 2231
RWLock.h 4281
SchedulerGroup.cpp SchedulerEventTarget 10123
SchedulerGroup.h 7673
SharedThreadPool.cpp static 7469
SharedThreadPool.h 4912
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. 13385
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. 9986
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. 5062
SyncRunnable.h This class will wrap a nsIRunnable and dispatch it to the main thread synchronously. This is different from nsIEventTarget.DISPATCH_SYNC: 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 a convenience wrapper: SyncRunnable::DispatchToThread(new myrunnable...()); 3476
SystemGroup.cpp aNeedValidation = 2433
SystemGroup.h 1427
TaskCategory.h 1050
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. 9637
TaskQueue.cpp passed by ref 7373
TaskQueue.h passed by ref 6894
ThreadBound.h 4665
ThreadDelay.cpp 1191
ThreadDelay.h 670
ThreadEventQueue.cpp 9101
ThreadEventQueue.h 3227
ThreadEventTarget.cpp 5956
ThreadEventTarget.h 1575
ThreadLocalVariables.cpp 513
ThrottledEventQueue.cpp 13846
ThrottledEventQueue.h 5164
TimerThread.cpp 23561
TimerThread.h TimerThread_h___ 3124