The Implementation

This section is intended for developing messaging internals. If any of this is useful to you as a client of IPDL then you probably made a wrong turn down a dark alley somewhere.

TODO:

• Define Chromium and Gecko entities

  • MessageLoop: Provides basic functionality for threads that run a loop that processes messages. Uses system primitives to avoid wastefully running wait loops.

    • MessageLoopForUI is a MessageLoop that adds the ability for the Windows event queue to process events, in addition to handling its own local messages. It is just a MessageLoop outside of Windows.

    • MessageLoopForIO is a MessageLoop that adds the ability for supported platforms to read from an OS-level IPC queue, in addition to handling its own local messages.

  • The I/O Thread: Has a MessageLoopForIO, used for all IPC between the process and all other processes. NB: Chromium code refers to this thread as the “main” thread, which it never is in our parlance.

  • MessagePump and base::MessagePump: Strategies for running messages queued in an nsIEventTarget. There are a ton of these – for different platforms, UI vs non-UI-capable handlers, main vs child processes, main thread vs off-main-thread handlers, etc. MessagePumpForIO is used by cross-process actors on the I/O thread.

  • MessageLink: abstract base class representing the two ways that actors communicate:

    • ThreadLink: Same-process actors use a queue between threads. Messages may even be dispatched in-line.

    • ProcessLink: Two-process actors use sockets (POSIX) or completion ports (Windows).

  • MessageChannel: Very beefy class where much of the Gecko (platform-agnostic) complexity resides. Boy, this sure could use some documentation…

• Discuss platform implementations + issues.

• Give a high-level overview of the IPDL compiler.

• IPDLParamTraits (vs ParamTraits)