Name Description Size
AsyncBlockers.h AsyncBlockers provide a simple registration service that allows to suspend completion of a particular task until all registered entries have been cleared. This can be used to implement a similar service to nsAsyncShutdownService in processes where it wouldn't normally be available. This class is thread-safe. 2864
BackgroundChild.h 2498
BackgroundChildImpl.cpp 14859
BackgroundChildImpl.h 6571
BackgroundImpl.cpp 39793
BackgroundParent.h 3610
BackgroundParentImpl.cpp 46242
BackgroundParentImpl.h 14411
BackgroundStarterChild.h 1262
BackgroundStarterParent.h 1669
BackgroundUtils.cpp 44546
BackgroundUtils.h Convert a PrincipalInfo to an nsIPrincipal. MUST be called on the main thread. 6147
BigBuffer.cpp 3542
BigBuffer.h 4207
BrowserProcessSubThread.cpp static 2135
BrowserProcessSubThread.h 2074
ByteBuf.h A type that can be sent without needing to make a copy during serialization. In addition the receiver can take ownership of the data to avoid having to make an additional copy. 1758
ByteBufUtils.h A type that can be sent without needing to make a copy during serialization. In addition the receiver can take ownership of the data to avoid having to make an additional copy. 2106
components.conf 807
CrashReporterClient.cpp static 1223
CrashReporterClient.h 1443
CrashReporterHelper.h This class encapsulates the common elements of crash report handling for toplevel protocols representing processes. To use this class, you should: 1. Declare a method to initialize the crash reporter in your IPDL: `async InitCrashReporter(NativeThreadId threadId)` 2. Inherit from this class, providing the appropriate `GeckoProcessType` enum value for the template parameter PT. 3. When your protocol actor is destroyed with a reason of `AbnormalShutdown`, you should call `GenerateCrashReport(OtherPid())`. If you need the crash report ID it will be copied in the second optional parameter upon successful crash report generation. 3169
CrashReporterHost.cpp static 6045
CrashReporterHost.h 5028
CrossProcessMutex.h CrossProcessMutex @param name A name which can reference this lock (currently unused) 3478
CrossProcessMutex_posix.cpp 3426
CrossProcessMutex_unimplemented.cpp 1357
CrossProcessMutex_windows.cpp 2030
CrossProcessSemaphore.h CrossProcessSemaphore @param name A name which can reference this lock (currently unused) 3301
CrossProcessSemaphore_mach.cpp static 3011
CrossProcessSemaphore_posix.cpp static 4278
CrossProcessSemaphore_unimplemented.cpp static 1913
CrossProcessSemaphore_windows.cpp static 2551
DataPipe.cpp 28166
DataPipe.h aReceiverSide 7128
Endpoint.cpp mOtherSide 6267
Endpoint.h An endpoint represents one end of a partially initialized IPDL channel. To set up a new top-level protocol: Endpoint<PFooParent> parentEp; Endpoint<PFooChild> childEp; nsresult rv; rv = PFoo::CreateEndpoints(&parentEp, &childEp); Endpoints can be passed in IPDL messages or sent to other threads using PostTask. Once an Endpoint has arrived at its destination process and thread, you need to create the top-level actor and bind it to the endpoint: FooParent* parent = new FooParent(); bool rv1 = parentEp.Bind(parent, processActor); bool rv2 = parent->SendBar(...); (See Bind below for an explanation of processActor.) Once the actor is bound to the endpoint, it can send and receive messages. If creating endpoints for a [NeedsOtherPid] actor, you're required to also pass in parentPid and childPid, which are the pids of the processes in which the parent and child endpoints will be used. 10498
EnumSerializer.h Generic enum serializer. Consider using the specializations below, such as ContiguousEnumSerializer. This is a generic serializer for any enum type used in IPDL. Programmers can define ParamTraits<E> for enum type E by deriving EnumSerializer<E, MyEnumValidator> where MyEnumValidator is a struct that has to define a static IsLegalValue function returning whether a given value is a legal value of the enum type at hand. \sa https://developer.mozilla.org/en/IPDL/Type_Serialization 6156
EnvironmentMap.h 2328
ExtensionKitUtils.h 2450
ExtensionKitUtils.mm 4407
FileDescriptor.cpp 3445
FileDescriptor.h 2545
FileDescriptorShuffle.cpp 3720
FileDescriptorShuffle.h 2353
FileDescriptorUtils.cpp 2706
FileDescriptorUtils.h 1643
ForkServer.cpp Preload any resources that the forked child processes might need, and which might change incompatibly or become unavailable by the time they're started. For example: the omnijar files, or certain shared libraries. 10196
ForkServer.h 1134
ForkServiceChild.cpp 7643
ForkServiceChild.h This is the interface to the fork server. When the chrome process calls |ForkServiceChild| to create a new process, this class send a message to the fork server through a pipe and get the PID of the new process from the reply. 3192
GeckoChildProcessHost.cpp 67878
GeckoChildProcessHost.h 11650
IdleSchedulerChild.cpp 4836
IdleSchedulerChild.h 2172
IdleSchedulerParent.cpp 15242
IdleSchedulerParent.h 4748
InputStreamParams.ipdlh 1971
InputStreamUtils.cpp 7361
InputStreamUtils.h 2046
IOThreadChild.h stack size 1534
IPCCore.h 633
IPCForwards.h 1212
IPCMessageUtils.h A helper class for serializing empty structs. Since the struct is empty there is nothing to write, and a priori we know the result of the read. 7607
IPCMessageUtilsSpecializations.cpp static 2017
IPCMessageUtilsSpecializations.h 25236
IPCStream.ipdlh 679
IPCStreamUtils.cpp 5780
IPCStreamUtils.h 1770
IPCTypes.h 631
IPDLParamTraits.h 2252
IPDLStructMember.h 1292
LaunchError.h 2710
MessageChannel.cpp IPC design: There are two kinds of messages: async and sync. Sync messages are blocking. Terminology: To dispatch a message Foo is to run the RecvFoo code for it. This is also called "handling" the message. Sync and async messages can sometimes "nest" inside other sync messages (i.e., while waiting for the sync reply, we can dispatch the inner message). The three possible nesting levels are NOT_NESTED, NESTED_INSIDE_SYNC, and NESTED_INSIDE_CPOW. The intended uses are: NOT_NESTED - most messages. NESTED_INSIDE_SYNC - CPOW-related messages, which are always sync and can go in either direction. NESTED_INSIDE_CPOW - messages where we don't want to dispatch incoming CPOWs while waiting for the response. These nesting levels are ordered: NOT_NESTED, NESTED_INSIDE_SYNC, NESTED_INSIDE_CPOW. Async messages cannot be NESTED_INSIDE_SYNC but they can be NESTED_INSIDE_CPOW. To avoid jank, the parent process is not allowed to send NOT_NESTED sync messages. When a process is waiting for a response to a sync message M0, it will dispatch an incoming message M if: 1. M has a higher nesting level than M0, or 2. if M has the same nesting level as M0 and we're in the child, or 3. if M has the same nesting level as M0 and it was sent by the other side while dispatching M0. The idea is that messages with higher nesting should take precendence. The purpose of rule 2 is to handle a race where both processes send to each other simultaneously. In this case, we resolve the race in favor of the parent (so the child dispatches first). Messages satisfy the following properties: A. When waiting for a response to a sync message, we won't dispatch any messages of a lower nesting level. B. Messages of the same nesting level will be dispatched roughly in the order they were sent. The exception is when the parent and child send sync messages to each other simulataneously. In this case, the parent's message is dispatched first. While it is dispatched, the child may send further nested messages, and these messages may be dispatched before the child's original message. We can consider ordering to be preserved here because we pretend that the child's original message wasn't sent until after the parent's message is finished being dispatched. When waiting for a sync message reply, we dispatch an async message only if it is NESTED_INSIDE_CPOW. Normally NESTED_INSIDE_CPOW async messages are sent only from the child. However, the parent can send NESTED_INSIDE_CPOW async messages when it is creating a bridged protocol. 80979
MessageChannel.h 31144
MessageLink.cpp 6384
MessageLink.h 2804
MessagePump.cpp namespace ipc 9935
MessagePump.h 5815
MessagePump_android.cpp 921
MessagePump_mac.mm 3270
MessagePump_windows.cpp 2843
MiniTransceiver.cpp Initialize the IO vector for sending data and the control buffer for sending FDs. 7778
MiniTransceiver.h This simple implementation handles the transmissions of IPC messages. It works according to a strict request-response paradigm, no concurrent messaging is allowed. Sending a message from A to B must be followed by another one from B to A. Because of this we don't need to handle data crossing the boundaries of a message. Transmission is done via blocking I/O to avoid the complexity of asynchronous I/O. 3679
moz.build 7950
Neutering.h This header declares RAII wrappers for Window neutering. See WindowsMessageLoop.cpp for more details. 1849
NodeChannel.cpp 10085
NodeChannel.h 6493
NodeController.cpp static 31568
NodeController.h 7136
nsIIPCSerializableInputStream.h 5270
PBackground.ipdl Issue an asynchronous request that will be used in a synchronous fashion through complex machinations described in `PBackgroundLSRequest.ipdl` and `LSObject.h`. 9395
PBackgroundSharedTypes.ipdlh 1907
PBackgroundStarter.ipdl 461
PBackgroundTest.ipdl 551
PIdleScheduler.ipdl PIdleScheduler is the protocol for cross-process idle scheduling. Only child processes participate in the scheduling and parent process can run its idle tasks whenever it needs to. The scheduler keeps track of the following things. - Activity of the main thread of each child process. A process is active when it is running tasks. Because of performance cross-process counters in shared memory are used for the activity tracking. There is one counter counting the activity state of all the processes and one counter for each process. This way if a child process crashes, the global counter can be updated by decrementing the per process counter from it. - Child processes running prioritized operation. Top level page loads is an example of a prioritized operation. When such is ongoing, idle tasks are less likely to run. - Idle requests. When a child process locally has idle tasks to run, it requests idle time from the scheduler. Initially requests go to a wait list and the scheduler runs and if there are free logical cores for the child processes, idle time is given to the child process, and the process goes to the idle list. Once idle time has been consumed or there are no tasks to process, child process informs the scheduler and the process is moved back to the default queue. 2897
ProcessChild.cpp static 4729
ProcessChild.h Exit *now*. Do not shut down XPCOM, do not pass Go, do not run static destructors, do not collect $200. 2381
ProcessUtils.h 2888
ProcessUtils_bsd.cpp 703
ProcessUtils_common.cpp read_only 6087
ProcessUtils_linux.cpp 590
ProcessUtils_mac.mm 3626
ProcessUtils_none.cpp 500
ProtocolMessageUtils.h 4033
ProtocolTypes.ipdlh 486
ProtocolUtils.cpp static 28198
ProtocolUtils.h 30484
PUtilityAudioDecoder.ipdl 1641
PUtilityProcess.ipdl This method is used to notify a child process to start processing module loading events in UntrustedModulesProcessor. This should be called when the parent process has gone idle. 4754
RandomAccessStreamParams.ipdlh 857
RandomAccessStreamUtils.cpp 2745
RandomAccessStreamUtils.h 1561
RawShmem.cpp 3208
RawShmem.h 3780
RustMessageUtils.h TODO: Should be able to initialize `result` in-place instead 2726
ScopedPort.cpp 2138
ScopedPort.h 2315
SerializedStructuredCloneBuffer.cpp 3123
SerializedStructuredCloneBuffer.h __IPC_GLUE_SERIALIZEDSTRUCTUREDCLONEBUFFER_H__ 2585
SetProcessTitle.cpp 1178
SetProcessTitle.h 596
SharedMemory.cpp 3657
SharedMemory.h 2207
SharedMemory_posix.cpp 1521
SharedMemory_windows.cpp 1125
SharedMemoryImpl_chromium.cpp 1509
SharedMemoryImpl_chromium.h 1307
SharedMemoryImpl_mach.cpp nothing 5217
SharedMemoryImpl_mach.h 1476
Shmem.cpp 6949
Shmem.h |Shmem| is one agent in the IPDL shared memory scheme. The way it works is essentially (1) C++ code calls, say, |parentActor->AllocShmem(size)| (2) IPDL-generated code creates a |mozilla::ipc::SharedMemory| wrapping the bare OS shmem primitives. The code then adds the new SharedMemory to the set of shmem segments being managed by IPDL. (3) IPDL-generated code "shares" the new SharedMemory to the child process, and then sends a special asynchronous IPC message to the child notifying it of the creation of the segment. (What this means is OS specific.) (4a) The child receives the special IPC message, and using the |SharedMemory::Handle| it was passed, creates a |mozilla::ipc::SharedMemory| in the child process. (4b) After sending the "shmem-created" IPC message, IPDL-generated code in the parent returns a |mozilla::ipc::Shmem| back to the C++ caller of |parentActor->AllocShmem()|. The |Shmem| is a "weak reference" to the underlying |SharedMemory|, which is managed by IPDL-generated code. C++ consumers of |Shmem| can't get at the underlying |SharedMemory|. If parent code wants to give access rights to the Shmem to the child, it does so by sending its |Shmem| to the child, in an IPDL message. The parent's |Shmem| then "dies", i.e. becomes inaccessible. This process could be compared to passing a "shmem-access baton" between parent and child. 5908
ShmemMessageUtils.h 938
SideVariant.h Helper type used by IPDL structs and unions to hold actor pointers with a dynamic side. When sent over IPC, ParentSide will be used for send/recv on parent actors, and ChildSide will be used for send/recv on child actors. 6068
StringUtil.cpp 2610
TaintingIPCUtils.h 1269
TaskFactory.h This is based on the ScopedRunnableMethodFactory from ipc/chromium/src/base/task.h Chromium's factories assert if tasks are created and run on different threads, which is something we need to do in PluginModuleParent (hang UI vs. main thread). TaskFactory just provides cancellable tasks that don't assert this. This version also allows both ScopedMethod and regular Tasks to be generated by the same Factory object. 2881
test
ToplevelActorHolder.h 1390
TransportSecurityInfoUtils.cpp 1806
TransportSecurityInfoUtils.h 1699
URIParams.ipdlh 2032
URIUtils.cpp 3627
URIUtils.h 1432
UtilityAudioDecoder.cpp 1357
UtilityAudioDecoder.h 799
UtilityAudioDecoderChild.cpp static 9806
UtilityAudioDecoderChild.h 3351
UtilityAudioDecoderParent.cpp static 7006
UtilityAudioDecoderParent.h 2048
UtilityProcessChild.cpp static 13407
UtilityProcessChild.h 3850
UtilityProcessHost.cpp remoteType 12884
UtilityProcessHost.h 5967
UtilityProcessImpl.cpp static 4346
UtilityProcessImpl.h 1341
UtilityProcessManager.cpp isLocked 23628
UtilityProcessManager.h 7482
UtilityProcessParent.cpp 6739
UtilityProcessParent.h 2708
UtilityProcessSandboxing.cpp 2143
UtilityProcessSandboxing.h 1133
WindowsMessageLoop.cpp The Windows-only code below exists to solve a general problem with deadlocks that we experience when sending synchronous IPC messages to processes that contain native windows (i.e. HWNDs). Windows (the OS) sends synchronous messages between parent and child HWNDs in multiple circumstances (e.g. WM_PARENTNOTIFY, WM_NCACTIVATE, etc.), even when those HWNDs are controlled by different threads or different processes. Thus we can very easily end up in a deadlock by a call stack like the following: Process A: - CreateWindow(...) creates a "parent" HWND. - SendCreateChildWidget(HWND) is a sync IPC message that sends the "parent" HWND over to Process B. Process A blocks until a response is received from Process B. Process B: - RecvCreateWidget(HWND) gets the "parent" HWND from Process A. - CreateWindow(..., HWND) creates a "child" HWND with the parent from process A. - Windows (the OS) generates a WM_PARENTNOTIFY message that is sent synchronously to Process A. Process B blocks until a response is received from Process A. Process A, however, is blocked and cannot process the message. Both processes are deadlocked. The example above has a few different workarounds (e.g. setting the WS_EX_NOPARENTNOTIFY style on the child window) but the general problem is persists. Once two HWNDs are parented we must not block their owning threads when manipulating either HWND. Windows requires any application that hosts native HWNDs to always process messages or risk deadlock. Given our architecture the only way to meet Windows' requirement and allow for synchronous IPC messages is to pump a miniature message loop during a sync IPC call. We avoid processing any queued messages during the loop (with one exception, see below), but "nonqueued" messages (see http://msdn.microsoft.com/en-us/library/ms644927(VS.85).aspx under the section "Nonqueued messages") cannot be avoided. Those messages are trapped in a special window procedure where we can either ignore the message or process it in some fashion. Queued and "non-queued" messages will be processed during Interrupt calls if modal UI related api calls block an Interrupt in-call in the child. To prevent windows from freezing, and to allow concurrent processing of critical events (such as painting), we spin a native event dispatch loop while these in-calls are blocked. 37160
WindowsMessageLoop.h namespace windows 3488