Confirmed users
431
edits
IPDL/Getting started: Difference between revisions
m
no edit summary
m (→Messages) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
IPDL is a domain-specific language that allows programmers to define a message-passing "protocol" between "actors." These "actors" are thread contexts, | IPDL is a domain-specific language that allows programmers to define a message-passing "protocol" between "actors." These "actors" are thread contexts, which can execute either in separate address spaces or within the same address space (shared-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. | 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. | ||
| Line 34: | Line 36: | ||
The above specification will generate three headers: PluginProtocolParent.h, PluginProtocolChild.h, and PluginProtocol.h (we'll ignore the third completely; it's full of uninteresting implementation details). As you might guess, PluginProtocolParent.h defines a C++ class (PluginProtocolParent) that code on the parent side utilizes, the browser in this example. And similarly, code running in the plugin process will use the PluginProtocolChild class. | The above specification will generate three headers: PluginProtocolParent.h, PluginProtocolChild.h, and PluginProtocol.h (we'll ignore the third completely; it's full of uninteresting implementation details). As you might guess, PluginProtocolParent.h defines a C++ class (PluginProtocolParent) that code on the parent side utilizes, the browser in this example. And similarly, code running in the plugin process will use the PluginProtocolChild class. | ||
These Parent and Child classes are "abstract" in the Java sense. The | These Parent and Child classes are "abstract" in the Java sense. The PluginProtocolParent class will look something like the following in C++ | ||
class PluginProtocolParent { | class PluginProtocolParent { | ||