| 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.
|
2747 |
100 % |
| BackgroundChild.h |
|
2341 |
- |
| BackgroundChildImpl.cpp |
|
13674 |
67 % |
| BackgroundChildImpl.h |
|
6008 |
0 % |
| BackgroundImpl.cpp |
|
39603 |
86 % |
| BackgroundParent.h |
|
3454 |
100 % |
| BackgroundParentImpl.cpp |
|
48881 |
82 % |
| BackgroundParentImpl.h |
|
14407 |
0 % |
| BackgroundStarterChild.h |
|
1141 |
100 % |
| BackgroundStarterParent.h |
|
1548 |
100 % |
| BackgroundUtils.cpp |
|
44513 |
89 % |
| BackgroundUtils.h |
Convert a PrincipalInfo to an nsIPrincipal.
MUST be called on the main thread.
|
5991 |
100 % |
| BigBuffer.cpp |
|
3590 |
81 % |
| BigBuffer.h |
|
4225 |
94 % |
| 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. |
1637 |
96 % |
| 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. |
1985 |
88 % |
| components.conf |
|
718 |
- |
| CrashReporterClient.cpp |
static |
2156 |
86 % |
| CrashReporterClient.h |
|
1310 |
100 % |
| 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 with the name of your derived class as the
type parameter. Ex: `class MyClass : public CrashReporterHelper<MyClass>`
3. Provide a public `PROCESS_TYPE` constant for your class. Ex:
```
public:
static constexpr GeckoProcessType PROCESS_TYPE =
GeckoProcessType_GMPlugin;
```
4. When your protocol actor is destroyed with a reason of `AbnormalShutdown`,
you should call `GenerateCrashReport()`. If you need the crash
report ID it will be copied in the second optional parameter upon
successful crash report generation.
|
3745 |
49 % |
| CrashReporterHost.cpp |
static |
7230 |
69 % |
| CrashReporterHost.h |
|
5006 |
18 % |
| CrossProcessMutex.h |
CrossProcessMutex
@param name A name which can reference this lock (currently unused)
|
3378 |
- |
| CrossProcessMutex_posix.cpp |
|
2960 |
41 % |
| CrossProcessMutex_unimplemented.cpp |
|
1236 |
- |
| CrossProcessMutex_windows.cpp |
|
1909 |
84 % |
| CrossProcessSemaphore.h |
CrossProcessSemaphore
@param name A name which can reference this lock (currently unused)
|
3058 |
100 % |
| CrossProcessSemaphore_mach.cpp |
static |
2890 |
- |
| CrossProcessSemaphore_posix.cpp |
static |
3726 |
78 % |
| CrossProcessSemaphore_unimplemented.cpp |
static |
1792 |
- |
| CrossProcessSemaphore_windows.cpp |
static |
2430 |
92 % |
| DataPipe.cpp |
|
27904 |
83 % |
| DataPipe.h |
aReceiverSide |
6754 |
74 % |
| EagerIPCStream.h |
|
627 |
- |
| Endpoint.cpp |
mOtherSide |
7430 |
79 % |
| 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.
|
10596 |
96 % |
| 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
|
6025 |
84 % |
| EnvironmentMap.h |
|
2207 |
- |
| ExtensionKitUtils.h |
|
2618 |
- |
| ExtensionKitUtils.mm |
|
4758 |
- |
| FileDescriptor.cpp |
|
2446 |
93 % |
| FileDescriptor.h |
|
2363 |
- |
| FileDescriptorShuffle.cpp |
|
3599 |
71 % |
| FileDescriptorShuffle.h |
|
2210 |
100 % |
| FileDescriptorUtils.cpp |
|
2581 |
35 % |
| FileDescriptorUtils.h |
|
1490 |
0 % |
| 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.
|
13185 |
0 % |
| ForkServer.h |
|
1138 |
0 % |
| ForkServiceChild.cpp |
|
9523 |
17 % |
| 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.
|
3952 |
0 % |
| GeckoChildProcessHost.cpp |
|
69110 |
80 % |
| GeckoChildProcessHost.h |
|
11766 |
89 % |
| IdleSchedulerChild.cpp |
|
4433 |
98 % |
| IdleSchedulerChild.h |
|
2058 |
88 % |
| IdleSchedulerParent.cpp |
|
15395 |
95 % |
| IdleSchedulerParent.h |
|
4100 |
67 % |
| InputStreamParams.ipdlh |
|
1963 |
- |
| InputStreamUtils.cpp |
|
7053 |
88 % |
| InputStreamUtils.h |
|
1925 |
- |
| IOThread.cpp |
static |
3311 |
96 % |
| IOThread.h |
|
2776 |
90 % |
| IPCCore.h |
|
512 |
100 % |
| IPCForwards.h |
|
1091 |
- |
| 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.
|
8267 |
97 % |
| IPCMessageUtilsSpecializations.cpp |
static |
1896 |
90 % |
| IPCMessageUtilsSpecializations.h |
|
26349 |
90 % |
| IPCStream.ipdlh |
|
679 |
- |
| IPCStreamUtils.cpp |
|
6437 |
85 % |
| IPCStreamUtils.h |
|
1937 |
- |
| IPCTypes.h |
|
510 |
- |
| IPDLStructMember.h |
|
1181 |
100 % |
| LaunchError.h |
|
2589 |
25 % |
| 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.
|
84982 |
83 % |
| 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.
|
29917 |
86 % |
| MessageLink.cpp |
|
6205 |
89 % |
| MessageLink.h |
|
2649 |
50 % |
| MessagePump.cpp |
namespace ipc |
9814 |
59 % |
| 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
|
5653 |
91 % |
| MessagePump_android.cpp |
|
800 |
- |
| MessagePump_mac.mm |
|
3155 |
- |
| MessagePump_windows.cpp |
|
2728 |
98 % |
| MiniTransceiver.cpp |
Initialize the IO vector for sending data and the control buffer for sending
FDs.
|
7657 |
0 % |
| 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.
|
3520 |
0 % |
| moz.build |
|
8229 |
- |
| Neutering.h |
This header declares RAII wrappers for Window neutering. See
WindowsMessageLoop.cpp for more details.
|
1728 |
0 % |
| NodeChannel.cpp |
|
9732 |
88 % |
| NodeChannel.h |
|
6332 |
78 % |
| NodeController.cpp |
static |
32610 |
87 % |
| NodeController.h |
|
7370 |
50 % |
| nsIIPCSerializableInputStream.h |
|
4804 |
- |
| PBackground.ipdl |
Issue an asynchronous request that will be used in a synchronous fashion
through complex machinations described in `PBackgroundLSRequest.ipdl` and
`LSObject.h`.
|
10197 |
- |
| PBackgroundSharedTypes.ipdlh |
|
2689 |
- |
| 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.
|
2852 |
- |
| ProcessChild.cpp |
static |
4290 |
93 % |
| ProcessChild.h |
Exit *now*. Do not shut down XPCOM, do not pass Go, do not run
static destructors, do not collect $200.
|
2264 |
71 % |
| ProcessUtils.h |
|
2490 |
100 % |
| ProcessUtils_bsd.cpp |
|
582 |
- |
| ProcessUtils_common.cpp |
|
4733 |
77 % |
| ProcessUtils_linux.cpp |
|
469 |
100 % |
| ProcessUtils_mac.mm |
|
3947 |
- |
| ProcessUtils_none.cpp |
|
379 |
100 % |
| ProtocolMessageUtils.h |
|
3282 |
100 % |
| ProtocolTypes.ipdlh |
|
363 |
- |
| ProtocolUtils.cpp |
static |
30921 |
75 % |
| ProtocolUtils.h |
|
31389 |
90 % |
| PUtilityMediaService.ipdl |
|
1597 |
- |
| 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.
|
5093 |
- |
| RandomAccessStreamParams.ipdlh |
|
857 |
- |
| RandomAccessStreamUtils.cpp |
|
2624 |
86 % |
| RandomAccessStreamUtils.h |
|
1440 |
- |
| RustMessageUtils.h |
TODO: Should be able to initialize `result` in-place instead |
2646 |
- |
| ScopedPort.cpp |
|
2017 |
96 % |
| ScopedPort.h |
|
2194 |
100 % |
| SerializedStructuredCloneBuffer.cpp |
|
3002 |
77 % |
| SerializedStructuredCloneBuffer.h |
IPC_GLUE_SERIALIZEDSTRUCTUREDCLONEBUFFER_H_ |
2267 |
100 % |
| SerializeToBytesUtil.h |
|
2139 |
96 % |
| SetProcessTitle.cpp |
|
1098 |
0 % |
| SetProcessTitle.h |
|
516 |
- |
| SharedMemoryCursor.cpp |
aWriteToShmem |
3419 |
90 % |
| SharedMemoryCursor.h |
|
3638 |
100 % |
| SharedMemoryHandle.cpp |
|
6861 |
87 % |
| SharedMemoryHandle.h |
The size of the shared memory region to which this handle refers.
|
8379 |
100 % |
| SharedMemoryMapping.cpp |
aOffset |
6122 |
84 % |
| SharedMemoryMapping.h |
A leaked memory mapping.
This memory will never be unmapped.
|
9132 |
100 % |
| SharedMemoryPlatform.h |
Functions that need to be implemented for each platform.
These are static methods of a class to simplify access (the class can be
made a friend to give access to platform implementations).
|
3998 |
- |
| SharedMemoryPlatform_android.cpp |
|
3906 |
- |
| SharedMemoryPlatform_mach.cpp |
nothing |
7196 |
- |
| SharedMemoryPlatform_posix.cpp |
|
15673 |
60 % |
| SharedMemoryPlatform_windows.cpp |
|
8106 |
69 % |
| Shmem.cpp |
unused |
6019 |
85 % |
| 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::SharedMemoryMapping|
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
|MutableSharedMemoryHandle| it was passed, creates a |SharedMemoryMapping|
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 |SharedMemoryMapping|.
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.
|
6082 |
91 % |
| ShmemMessageUtils.h |
|
679 |
- |
| 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.
|
5947 |
84 % |
| StringUtil.cpp |
|
2489 |
68 % |
| TaintingIPCUtils.h |
|
881 |
100 % |
| 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.
|
2760 |
95 % |
| test |
|
|
71 % |
| TransportSecurityInfoUtils.cpp |
|
1806 |
90 % |
| TransportSecurityInfoUtils.h |
|
1699 |
- |
| URIParams.ipdlh |
|
1975 |
- |
| URIUtils.cpp |
|
3446 |
87 % |
| URIUtils.h |
|
1325 |
92 % |
| UtilityMediaService.cpp |
|
1236 |
85 % |
| UtilityMediaService.h |
|
675 |
- |
| UtilityMediaServiceChild.cpp |
static |
8810 |
79 % |
| UtilityMediaServiceChild.h |
|
3331 |
100 % |
| UtilityMediaServiceParent.cpp |
static |
6964 |
81 % |
| UtilityMediaServiceParent.h |
|
1907 |
50 % |
| UtilityProcessChild.cpp |
static |
14049 |
87 % |
| UtilityProcessChild.h |
|
4338 |
40 % |
| UtilityProcessHost.cpp |
remoteType |
12517 |
86 % |
| UtilityProcessHost.h |
|
5811 |
86 % |
| UtilityProcessImpl.cpp |
static |
4396 |
37 % |
| UtilityProcessImpl.h |
|
1217 |
100 % |
| UtilityProcessManager.cpp |
isLocked |
24959 |
77 % |
| UtilityProcessManager.h |
|
7856 |
96 % |
| UtilityProcessParent.cpp |
|
6800 |
77 % |
| UtilityProcessParent.h |
|
2723 |
50 % |
| UtilityProcessSandboxing.cpp |
|
2401 |
79 % |
| UtilityProcessSandboxing.h |
|
1136 |
- |
| 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.
|
36993 |
16 % |
| WindowsMessageLoop.h |
namespace windows |
3367 |
0 % |