Name Description Size
AutoTransportDescriptor.cpp 1721
AutoTransportDescriptor.h 2512
BackgroundChild.h 2904
BackgroundChildImpl.cpp 22621
BackgroundChildImpl.h 10328
BackgroundImpl.cpp 52848
BackgroundParent.h 3823
BackgroundParentImpl.cpp 48541
BackgroundParentImpl.h 17143
BackgroundUtils.cpp 35973
BackgroundUtils.h Convert a PrincipalInfo to an nsIPrincipal. MUST be called on the main thread. 5542
BrowserProcessSubThread.cpp static 2135
BrowserProcessSubThread.h 2045
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. 2018
components.conf 807
CrashReporterClient.cpp static 1223
CrashReporterClient.h 1415
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. 2591
CrashReporterHost.cpp static 8681
CrashReporterHost.h 5173
CrossProcessMutex_posix.cpp 3417
CrossProcessMutex_unimplemented.cpp 1391
CrossProcessMutex_windows.cpp 2034
CrossProcessMutex.h CrossProcessMutex @param name A name which can reference this lock (currently unused) 3436
CrossProcessSemaphore_posix.cpp static 4263
CrossProcessSemaphore_unimplemented.cpp static 1947
CrossProcessSemaphore_windows.cpp static 2527
CrossProcessSemaphore.h CrossProcessSemaphore @param name A name which can reference this lock (currently unused) 3261
Endpoint.cpp mOtherSide 5510
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(parentPid, childPid, &parentEp, &childEp); You're required to pass in parentPid and childPid, which are the pids of the processes in which the parent and child endpoints will be used. 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. 7460
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 6125
EnvironmentMap.h 2346
FileDescriptor.cpp auto_close 4954
FileDescriptor.h 3539
FileDescriptorSetChild.cpp 1007
FileDescriptorSetChild.h 1447
FileDescriptorSetParent.cpp 1083
FileDescriptorSetParent.h 1526
FileDescriptorShuffle.cpp 3720
FileDescriptorShuffle.h 2353
FileDescriptorUtils.cpp 2706
FileDescriptorUtils.h 1643
ForkServer.cpp Prepare an environment for running a fork server. 9326
ForkServer.h 1133
ForkServiceChild.cpp 6018
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. 3065
GeckoChildProcessHost.cpp 60888
GeckoChildProcessHost.h 10291
IdleSchedulerChild.cpp 4831
IdleSchedulerChild.h 2172
IdleSchedulerParent.cpp 15420
IdleSchedulerParent.h 5012
InputStreamParams.ipdlh 2381
InputStreamUtils.cpp 14204
InputStreamUtils.h 4199
IOThreadChild.h 1415
IPCCore.h 633
IPCMessageUtils.cpp 731
IPCMessageUtils.h A helper class for serializing plain-old data (POD) structures. The memory representation of the structure is written to and read from the serialized stream directly, without individual processing of the structure's members. Derive ParamTraits<T> from PlainOldDataSerializer<T> if T is POD. Note: For POD structures with enumeration fields, this will not do validation of the enum values the way serializing the fields individually would. Prefer serializing the fields individually in such cases. 9423
IPCMessageUtilsSpecializations.cpp static 2027
IPCMessageUtilsSpecializations.h 28399
IPCStream.ipdlh 675
IPCStreamAlloc.h 718
IPCStreamChild.cpp static 4132
IPCStreamDestination.cpp 11307
IPCStreamDestination.h 2542
IPCStreamParent.cpp static 4236
IPCStreamSource.cpp 7963
IPCStreamSource.h 4090
IPCStreamUtils.cpp 19696
IPCStreamUtils.h do something with the nsIInputStream 7591
IPCTypes.h 631
IPDLParamTraits.h 15581
LibrarySandboxPreload.cpp 1297
LibrarySandboxPreload.h 548
MessageChannel.cpp 91715
MessageChannel.h This sends a special message that is processed on the IO thread, so that other actors can know that the process will soon shutdown. 31109
MessageLink.cpp 6501
MessageLink.h 2450
MessagePump.cpp namespace ipc 12960
MessagePump.h ` The MessagePumpForAndroidUI exists to enable IPDL in the Android UI thread. The Android UI thread event loop is controlled by Android. This prevents running an existing MessagePump implementation in the Android UI thread. In order to enable IPDL on the Android UI thread it is necessary to have a non-looping MessagePump. This class enables forwarding of nsIRunnables from MessageLoop::PostTask_Helper to the registered nsIEventTarget with out the need to control the event loop. The only member function that should be invoked is GetXPCOMThread. All other member functions will invoke MOZ_CRASH 4980
MiniTransceiver.cpp Initialize the IO vector for sending data and the control buffer for sending FDs. 7418
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. 3628 6949
Neutering.h This header declares RAII wrappers for Window neutering. See WindowsMessageLoop.cpp for more details. 1849
NodeChannel.cpp 10036
NodeChannel.h 5303
NodeController.cpp static 25200
NodeController.h 6507
nsIIPCSerializableInputStream.h 6837
PBackground.ipdl 10035
PBackgroundSharedTypes.ipdlh 1821
PBackgroundTest.ipdl 496
PChildToParentStream.ipdl 1715
PFileDescriptorSet.ipdl 539
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. 2899
PParentToChildStream.ipdl 1715
ProcessChild.cpp static 1363
ProcessChild.h Exit *now*. Do not shut down XPCOM, do not pass Go, do not run static destructors, do not collect $200. 1598
ProcessUtils_bsd.cpp 703
ProcessUtils_common.cpp 10239
ProcessUtils_linux.cpp 590 3419
ProcessUtils_none.cpp 500
ProcessUtils.h 2891
ProtocolMessageUtils.h 4068
ProtocolTypes.ipdlh 486
ProtocolUtils.cpp 30700
ProtocolUtils.h 28692
ProtocolUtilsFwd.h 525
ScopedPort.cpp 2205
ScopedPort.h 2345
ScopedXREEmbed.cpp 2434
ScopedXREEmbed.h namespace ipc 820
SharedMemory_posix.cpp 1547
SharedMemory_windows.cpp 1151
SharedMemory.cpp static 2331
SharedMemory.h 4611
SharedMemoryBasic_android.cpp unused 3304
SharedMemoryBasic_android.h 2048
SharedMemoryBasic_chromium.h 2644
SharedMemoryBasic_mach.h 3012 nothing 24629
SharedMemoryBasic.h 669
Shmem.cpp 14804
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{Basic}::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. 7161
ShmemMessageUtils.h 1037
StringUtil.cpp 2656
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
Transport_posix.cpp close after sending 2604
Transport_posix.h 1047
Transport_win.cpp 3637
Transport_win.h 3387
Transport.h 1306
TransportSecurityInfoUtils.cpp 1786
TransportSecurityInfoUtils.h 977
URIParams.ipdlh 1921
URIUtils.cpp 3466
URIUtils.h 1424
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 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. 46421
WindowsMessageLoop.h namespace windows 3488