Re: The behavior of constructors in IPDL

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]

> 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.

--BDS