Re: The behavior of constructors in IPDL

On 7/24/09 11:39 AM, Chris Jones wrote:

> 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();

No, I don't think it would. The parent-generated IDs would be sequential

0x80000000
0x80000001
0x80000002 etc...

The child-generated IDs would also be sequential

0x00000000
0x00000001 etc...

There would be no chance of racing.

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

The client code will want to use the returned nsIChannel immediately after
it has been created (before the other side's routing ID is known). Would the
client code have to implement a check:

* Channel::Open
** Is the routing ID known yet? if not, queue up the message until the
routing ID is known

Or would the protocol implementation itself perform this check?

--BDS