Re: The behavior of constructors in IPDL

Benjamin Smedberg wrote:
> On 7/24/09 12:08 PM, Chris Jones wrote:
> 
>> P                  C
>> -----              -----
>> send Foo()[1]      send Foo()[2]
>> recv Foo()[2]      recv Foo()[1]
>>
>> Each constructs a distinct actor, and the routing IDs are assigned
>> simulatenously.  Without resorting to something fancy and painful, how
>> can the parent-side actor assume what the child-side actor's routing ID
>> will be (and vice versa)?  Remember that the protocol also allows:
> 
> I must not have been clear. Routing IDs created by P will always have the
> high bit set, so this example would be
> 
> P                  C
> -----              -----
> send Foo()[0x80000001]      send Foo()[0x00000001]
> recv Foo()[0x00000001]      recv Foo()[0x80000001]
> 

No, sorry, I didn't read your proposal closely enough.  Clever
observation!  I think this works.  (We don't actually need to set the
high bit, since each side has its own set of routing IDs.)

>> It sounds like you want to hide asynchronous construction/setup under a
>> synchronous API.  That doesn't sound like a good idea to me; the "async
>> way" would be to have an "Channel::OnOpened" notification or something
>> like that.
>>
>> If you must do this, I'd recommend doing the checking and queuing in
>> nsIChannel.  I really don't want to add this to IPDL.
> 
> All of the current APIs that we're wrapping behave in this way. For example,
> client code may .send() an XMLHttpRequest() (opening a channel) and
> immediately .cancel() it before the channel has even been created. I expect
> that most of the clients we're currently talking about will behave in this
> way, and requiring each one of them to do this setup-checking separately
> will cause lots of pain.
> 

As long as we have a valid ID to which to route, what you want will work
--- you can send messages to the other side before it's actually created
the other-side actor.  This also means I can cut the "secret" response
message out of the async ctor impl.  Again, great observation!

Cheers,
Chris