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)