IPDL/Getting started: Difference between revisions

This code defines a <code>Plugin</code> protocol.  On the next three lines, the code declares two messages, <code>Init()</code> and <code>Deinit()</code>.  We will describe the messages in more detail in the next section.  To finish the introduction of protocols and actors, note the <code>'''child'''</code> keyword used on the 2nd line.  This keyword says that ''child'' "accepts", or "implements", the messages declared under that "child" label.  That is, the parent actor can send those messages to the child, but the child cannot send those messages to the parent.

It is very important to understand message semantics.  It's tempting to think of protocol messages as C++ function calls, but that's not very useful.  We'll delve into gory details of the above example to illustrate these semantics.  To keep the example as concrete as possible, we first need to take a detour into how the above example is translated into something that C++ code can utilize.

Please don't use RPC semantics.  RPC inherits (nearly) all the problems of sync messages, while adding more of its own.  Every time your code makes an RPC call, it must ensure that its state is "consistent" enough to handle every re-entrant (nested) call allowed by the IPDL state machine.  This is hard to get right.  (Why was RPC semantics added?  Basically for NPAPI plugins, for which we can't change any existing plugin code.)