506075 - Asynchronous protocol creation (constructor?)

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Benjamin Smedberg]

I'm creating a toplevel protocol for content processes from which all IFrameEmbeddings will be created.

I want something like:

async protocol ContentProcess
{
    manages IFrameEmbedding;

    async CreateFrame(MagicWindowHandle parentWidget) returns (new IFrameEmbedding parent);
};

And the C++ signature would be something like:

nsresult ContentProcessParent::CallCreateFrame(
    MagicWindowHandle parentWindow,
    IFrameEmbeddingParent* parent);

Is that possible/reasonable? Other suggestions for syntax/callsignature welcome. I know in advance that the method will hand back a new IFrameEmbedding, not one that already exists.

Comment 1

[Benjamin Smedberg]

In case it's not clear, this means that the async message isn't actually waiting for any return message, the message is one-way.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Just to be further clear, IPDL already has syntax for actor creation, it just doesn't currently support asynchronous constructors.  The reason is that the current constructor implementations will not pass an actor back to C++ until the constructor is sure that the actor in the other process has been successfully created.

So to support this, I can just relax that rule.  Attempting to use an actor returned from an asynchronous constructor before its sibling in the other process has been created will cause an error.

The example in comment 0 looks like the following

// this IPDL
protocol ContentProcess
{
    manages IFrameEmbedding;
child:
    IFrameEmbedding(MagicWindowHandle parentWidget);
};

// compiles to this C++, loosely
IFrameEmbeddingParent* ContentProcessParent::SendIFrameEmbeddingConstructor(
    MagicWindowHandle parentWindow);

Comment 3

[Benjamin Smedberg]

What do you mean "has been created"? Can't it just be fire-and-forget, i.e.

"create an IFrameEmbedding with routing ID 1234" and then just treat routing ID 1234 as valid?

Also don't you have to pass in a concrete class implementation of IFrameEmbeddingProtocolParent as the C++ implementation? e.g.

nsresult ContentProcessParent::SendIFrameEmbeddingConstructor(MagicWindowHandle parentWindow, IFrameEmbeddingProtocolParent* impl);

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #3)
> What do you mean "has been created"? Can't it just be fire-and-forget, i.e.
> 
> "create an IFrameEmbedding with routing ID 1234" and then just treat routing ID
> 1234 as valid?
> 

Both sides have to know each other's routing IDs before they can communicate, and a routing ID is only assigned when an actor is constructed.  There's no guarantee that the routing IDs on both sides will be the same, and I don't want to specify that (it's potentially hard to implement).

> Also don't you have to pass in a concrete class implementation of
> IFrameEmbeddingProtocolParent as the C++ implementation? e.g.
> 
> nsresult ContentProcessParent::SendIFrameEmbeddingConstructor(MagicWindowHandle
> parentWindow, IFrameEmbeddingProtocolParent* impl);

No, your concrete class provides a factory method, and IPDL calls it before sending a ctor message to the other side.  Ctors and dtors can travel in both directions, so the factory methods turned out to be a cleaner design.  This is all described here

https://wiki.mozilla.org/IPDL/Getting_started#Protocol_management

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Pushed
c3dd3518fd70 Chris Jones - bug 506075: shoehorn support for async ctors/dtors into IPDL

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This implementation was done too hastily.  For C++ implementations, it neither allows the side receiving the constructor message to notify the sender that the constructor is done, nor does it automatically invoke an |OnConstructorDone()|-type callback.

I think the latter is the way to go.  Thoughts, objections?

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

bsmedberg observed a property of ctors that leads to a much better implementation: since message delivery is in-order, each side already knows what routing ID will be assigned on the other side.  So the side that sends an async ctor message doesn't need to wait on a response from the other side before routing messages to it.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Pushed
9e528a72d1dd Chris Jones - Bug 506075: eliminate handshaking async constructor protocol, use smarter routing ID assignmen