Re: The behavior of constructors in IPDL

Benjamin Smedberg wrote:
> I'm trying to understand the behavior of constructors in IPDL. Please
> correct me if any of the following statements are incorrect:
> 
> *  A sub-protocol must be created using the constructor method in the
> manager protocol
> 

Yes.  Same goes for destruction.

> * When the constructor is asynchronous, it doesn't behave like other
> asynchronous messages: there is an undeclared response message which gives
> the sending message the child routing ID of the new protocol.
> 

Yes, though I should emphasize that this is hidden from the C++
implementation classes.

> * There is currently no callback function for protocol implementers to know
> when an async constructor has gotten the response message with the child
> routing ID.
> 

Yes, but this can be added.

> I think that this model doesn't match the way people are going to expect to
> program, especially when everything is asynchronous. For example, if you're
> modeling this networking call asynchronously:
> 
> network->NewChannel(nsACString& spec, nsIChannel **result);
> 
> The protocols would be:
> 
> protocol Network
> {
>   manages Channel;
> 
> parent:
>   NewChannel(nsACString spec);
> };
> 
> Apart from wishing that the method name were "NewChannel" and not "Channel",

Why?  The benefit is concise |~Channel()| syntax, and not reserving
names for no particular reason.  "Channel" couldn't be used otherwise
because it names a protocol type.  "NewChannel" is an undistinguished
identifier.

> I need to have a notification (on ChannelProtocolChild) when the Channel
> object is ready to use, *or* I need the code to accept and queue message
> calls on the Channel before the child routing ID is received and send them
> once the channel is actually ready.
> 

Yes, I see what you're angling at: the async notification is necessary.
 The async implementation I hacked in yesterday is insufficient, as
there's not an easy way to discover when the actors are usable.

> Chris, you said in https://bugzilla.mozilla.org/show_bug.cgi?id=506075#c4
> that the routing IDs will be different on the child and the parent and
> that's why you have to have a response message. I don't understand why this
> has to be the case. Instead, can't the side which is creating the actor
> create a new serial ID and send it to the other side, e.g.
> 

No.  IPDL now allows limited "simultaneous" messages through the
"Diamond Rule."  This works because we assume that if the programmer
declares messages according to the Diamond Rule, then messages are
"commutative," i.e., can be processed in either order.  Specifying that
routing IDs must be the same on both the parent and child means that
constructor messages are no longer commutative, because routing IDs are
assigned based on the order the messages are processed.  An innocuous
protocol like this would break if we specify what you want:

  manages Foo; manages Bar;
  parent: Foo();
  child: Bar();

> If both parents and children can create the protocol, a flag bit could be
> used to distinguish between them and avoid races creating routing IDs.
> 

This is a lot of pain for undemonstrated gain.  How would notification
that an sync constructor finished not work for you?

Cheers,
Chris