IPDL/Getting started

IPDL is a domain-specific language that allows programmers to define a message-passing "protocol" between "actors." These "actors" are thread contexts, and they can execute both in separate address spaces or the same address space (share-nothing threads). "Protocols" consist of two elements: declarations of messages that can be exchanged between two actors, and the definition of a state machine that describes when each message is allowed to be sent.

From an IPDL specification, several C++ headers are generated. These headers are meant to be opaque to the author of an IPDL specification; internally, they manage the tedious details of setting up and tearing down the underlying communication layer (sockets and pipes), constructing and sending messages, ensuring that all actors adhere to their specifications, and "correctly" handling errors.

This guide intends to introduce the basic concepts of IPDL through an increasingly complicated example. By the end of the guide, you should be able to write IPDL specs and the C++ implementations of message handlers. This guide does not attempt to cover how IPDL works under the covers.

Running example: Browser plugins

We will use the example of a web browser launching plugins in separate processes and then controlling them. A plugin here is a dynamically loaded code module, such as libflash.so. Once a plugin module has been loaded, the browser can ask the plugin module to create instances. A plugin instance is what lives inside an object frame on a particular web page; a single youtube video is a Flash plugin instance, for example. There can be any number of plugin instances per plugin module. (There can be any number of youtube videos open in a web browser.)

Plugin instances are scriptable, which means that they can access JavaScript objects in the browser, and the browser can access JavaScript objects created by the plugin instance. Using the youtube Flash video example again, the youtube instance can create a JavaScript object that represents the video player, and the browser can access that video player object and ask it to "Pause," "Play," etc. There can be any number of script objects per plugin instance.

Protocols and actors

Protocols define how two actors communicate. We'll introduce protocols and actors using the plugin modules described above. Recall that in this example, we have two processes: the browser process and the process in which the plugin module's code executes. There are two actors: the thread context in which the browser's plugin management code executes (in the browser process), and the thread on which the plugin's code executes (in the plugin process).

We have chosen to codify the concept of parent and child actors in IPDL; we use "parent actor" to refer to the "more trusted" actor, and "child actor" to refer to the "less trusted" actor. In the case of plugins, the browser actor is the parent, and the plugin actor is the child.

The parent and child actors communicate by sending messages to each other. The messages that can be exchanged are explicitly declared in IPDL. The following IPDL code defines a very basic interaction of browser and plugin actors

 protocol Plugin {
   out Init();
   out Deinit();
 };

This code defines a Plugin protocol. On the next two lines, the code declares two messages, Init() and Deinit(). We will describe the messages in more detail in the next section. To finish the introduction of protocols and actors, note the out keywords used on the 2nd and 3rd lines. This keyword defines the direction of the message --- that is, whether the message is sent from the parent actor to the child, from the child to the parent, or both ways.

Important: protocols are written from the perspective of the parent actor. An out specifier means that the message is only sent out from the parent, to the child. This choice was completely arbitrary.

Messages

Next.