mozilla

Compare Revisions

IPDL Tutorial

Change Revisions

Revision 69590:

Revision 69590 by azakai on

Revision 69591:

Revision 69591 by jdm on

Title:
IPDL Tutorial
IPDL Tutorial
Slug:
IPDL/Tutorial
IPDL/Tutorial
Content:

Revision 69590
Revision 69591
n429// ----- file PPlugin.ipdln429<code>// ----- file PPlugin.ipdl  include protocol PPluginInstanc
 >e;  rpc protocol PPlugin {   manages PPluginInstance;  child:   r
 >pc Init(nsCString pluginPath) returns (bool ok);    <span style="
 >font-weight: bold;">rpc </span>PPluginInstance(nsCString type, ns
 >CString[] args) returns (int rv); </code>};
430include protocol "PPluginInstance.ipdl";430</pre>
431 431    <pre>
432rpc protocol PPlugin432<code>// ----- file PPluginInstance.ipdl  include protocol PPlugi
 >n;  rpc protocol PPluginInstance {   manager PPlugin;  child:   r
 >pc __delete__();    SetSize(int width, int height); };</code>
433{
434  manages PPluginInstance;
435 
436child:
437  rpc Init(nsCString pluginPath) returns (bool ok);
438 
439  <span style="font-weight: bold;">rpc </span>PluginInstance(nsCS
>tring type, nsCString[] args) returns (int rv); 
440  rpc ~PluginInstance();
441}
442 
443// ----- file PPluginInstance.ipdl
444 
445include protocol "PPlugin.ipdl";
446 
447rpc protocol PPluginInstance
448{
449  manager PPlugin;
450 
451child:
452  void SetSize(int width, int height);
453};
n462      The constructor and destructor messages have syntax similarn441      The mandatory constructor and destructor messages (PPluginI
> to C++ constructors, but the behavior is different. Constructors>nstance and __delete__ respectively) exist, confusingly, in separ
> and destructors have parameters, direction, semantics, and retur>ate locations. &nbsp;The constructor must be located in the manag
>n values like other IPDL messages. A constructor and destructor m>ing protocol, while the destructor belongs to the managed subprot
>essage must be declared for each managed protocol.>ocol. &nbsp;These messages have syntax similar to C++ constructor
 >s, but the behavior is different. Constructors and destructors ha
 >ve parameters, direction, semantics, and return values like other
 > IPDL messages. A constructor and destructor message must be decl
 >ared for each managed protocol.
nn448    </p>
449    <p>
450      Note: __delete__ is a built-in construct, and is the only I
 >PDL message which does not require an overridden implementation (
 >ie. Recv/Answer__delete__). &nbsp;However, overridden implementat
 >ions are encouraged when some action should happen on protocol de
 >struction in lieu of using the DeallocPProtocol function.
n487  virtual bool CallPPluginInstanceDestructor(PPluginInstanceParenn469  virtual bool Call__delete__(PPluginInstanceParent* actor) { /* 
>t* actor) { /* generated code */ }>generated code */ }
470 
471  /* Notification that actor deallocation is imminent, IPDL mecha
 >nisms are now unusable */
472  virtual void ActorDestroy(ActorDestroyReason why);
n504  virtual bool AnswerPPluginInstanceDestructor(PPluginInstanceChin489  virtual bool Answer__delete__(PPluginInstanceChild* actor) = 0;
>ld* actor) = 0; 
490 
491  /* Notification that actor deallocation is imminent, IPDL mecha
 >nisms are now unusable */
492  virtual void ActorDestroy(ActorDestroyReason why);
nn538    <p>
539      It is worth understanding the protocol deletion process. &n
 >bsp;Given the simple protocol:
540    </p>
541    <pre>
542async protocol PExample
543{
544parent:
545  PChild();
546};
547 
548async protocol PSubExample
549{
550child:
551  __delete__();
552};<br>
553</pre>
554    <p>
555      We assume that there is a PSubExampleParent/Child pair in e
 >xistence, such that some element now wishes to trigger the protoc
 >ol's deletion from the parent side.
556    </p>
557    <p>
558      <code>aPSubExampleParent-&gt;Send__delete__();</code>
559    </p>
560    <p>
561      will trigger the following ordered function calls:
562    </p>
563    <pre>
564PSubExampleParent::ActorDestroy(Deletion) /* Deletion is an enume
 >rated value indicating that the destruction was intentional */
565PExampleParent::DeallocPSubExample()
566</pre>
567    <pre>
568PSubExampleChild::Recv__delete__()
569PSubExampleChild::ActorDestroy(Deletion)
570PExampleChild::DeallocPSubExample()
571</pre>
572    <p>
573      ActorDestroy is a generated function that allows code to ru
 >n with the knowledge that actor deallocation is imminent. &nbsp;T
 >his is useful for actors with lifetimes outside of IPDL - for ins
 >tance, a flag could be set indicating that IPDL-related functions
 > are no longer safe to use.
574    </p>
tt578    <p>
579      &nbsp;
580    </p>&lt;meta http-equiv="content-type" content="text/html; ch
 >arset=utf-8"/&gt;

Back to History