Re: IPDL constructors... pre-created object

Benjamin Smedberg wrote:
> Currently when client code calls an IPDL constructor, it uses:
> 
> ProtocolParent->CallSubProtocolConstructor(...);
> 
> Internally, this will call a virtual function to create a new
> SubProtocolParent object:
> 
> ProtocolParent::SubProtocolConstructor(...)
> {
>   return new SubProtocolParent(...);
> }
> 
> When *receiving* a constructor function, I understand that it is necessary
> to have the pure-virtual constructor. But when *calling* a constructor, I'd
> prefer to pre-create the parent. This would involve a change to the
> CallSubProtocolConstructor signature:
> 
> ToplevelProtocolParent::CallSubProtocolConstructor(SubprotocolProtocolParent*,
> args...);
> 
> I specifically want to do this because I need to create the subprotocol
> parent with extra private data... data which is not being sent across the
> wire in the IPC message, but is stored as a member in the SubprotocolParent
> class.
> 
> Chris, does this sound like a reasonable change?
> 

After an IRC chat, we worked out something I'm OK with.  I'll overload 
the |SendCtor()| method with another that takes a first param that's a 
pointer to the actor's abstract class.

   Foo* SendFooCtor(...);          // (1)
   Foo* SendFooCtor(Foo* f, ...);  // (2)

The semantics of this parameter is to transfer ownership of the instance 
to IPDL.  In that way, if the constructor fails for whatever reason, we 
can destroy the Foo* as we would have for ctor (1), and still return NULL.

It's *strongly* recommended to invoke ctor (2) as follows

   Foo* f = SendFooCtor(new Foo(), ...);
   if (!f) ...

This is an easy way to make sure you don't have dangling pointers to the 
nascent actor (who might be killed on error).  We may later enforce this 
with a static analysis pass.

Cheers,
Chris