IPC and IPDL

Mozilla's inter-process plumbing lives in ipc/. It provides the IPDL language for declaring per-protocol actors, the message channel that actually moves bytes between processes, shared memory primitives, and integration with the cycle collector and scheduler.

Concepts

• Protocol — a typed conversation between two processes. Defined in a .ipdl file. Generates PFooParent and PFooChild C++ classes.
• Actor — an instance of a protocol endpoint, anchored to one side (parent or child).
• Manager / managee — actors form a tree: a parent actor manages child actors. The top-level actor is PContent, PGMP, PGPU, etc.
• Message — a one-way function call or reply.
• Sync vs async — sync messages block the sender until the receiver replies; discouraged but used for legacy paths.

A simple .ipdl

namespace mozilla {
namespace dom {

protocol PMyService {
    parent:
        async DoWork(int32_t aValue) returns (nsresult aRv);
    child:
        async Notify(nsString aMessage);
};

}
}

The compiler in ipc/ipdl/ emits:

• PMyServiceParent.h, PMyServiceChild.h — abstract bases with RecvDoWork, RecvNotify virtuals.
• Serialization for nsresult, nsString, etc.
• Refcounting and lifetime management hooks.

Directory layout

ipc/
├── ipdl/                # The IPDL compiler (Python)
├── glue/                # Channel, transport, process host, message protocol
│   ├── GeckoChildProcessHost.cpp
│   ├── MessageChannel.cpp
│   ├── MessageLink.cpp
│   ├── ProtocolUtils.{h,cpp}
│   ├── ScopedPort.h
│   ├── SharedMemory.{h,cpp}
│   └── ...
├── chromium/            # Vendored Chromium IPC primitives (legacy)
├── mscom/               # Windows COM marshaling
└── ...

How it ties to processes

graph LR
    Parent[Parent process] -->|fork+exec| Child[Child process]
    Parent -->|stdin/stdout/socket pair| Channel[MessageChannel]
    Child -->|stdin/stdout/socket pair| Channel
    Channel -->|messages| ParentActor["PContentParent (manager root)"]
    Channel -->|messages| ChildActor["PContentChild (manager root)"]
    ParentActor -->|manages| SubP1["PFooParent"]
    ChildActor -->|manages| SubC1["PFooChild"]

Top-level protocols include PContent (dom/ipc/PContent.ipdl), PGMP (gecko media plugin), PGPU, PSocketProcess, PUtilityProcess, PRDDProcess. They each have their own .ipdl.

JSActors

For lightweight per-document IPC in JS, JSActors (dom/ipc/JSActor.cpp, dom/ipc/JSWindowActor*, dom/ipc/JSProcessActor*) provide a declarative model:

• Register a name and a parent and child module pair via ChromeUtils.registerWindowActor(...) (often in BrowserGlue.sys.mjs).
• The framework instantiates an actor pair per document.
• Each side calls sendQuery(name, payload) (returns a Promise) or sendAsyncMessage(name, payload).

This lets browser-chrome features add cross-process plumbing without writing IPDL.

Shared memory

For larger payloads, IPDL supports Shmem (allocated on one side, sent across) and SharedMemory regions (ipc/glue/SharedMemory*). WebRender and the GPU process use shared memory aggressively.

Tooling

• ./mach build regenerates IPDL output when .ipdl files change.
• ./mach lint --linter ipdl checks IPDL style.
• IPC fuzzing infrastructure lives under tools/fuzzing/.

Related

• Process model
• DOM
• Patterns and conventions