Re: RFC: Electrolysis manifesto: Chrome never blocks on content

Chris Jones wrote:
> Benjamin Smedberg wrote:
>> However, the content->chrome message still has to be RPC (instead of 
>> sync) for one reason: the return value from such a function may 
>> contain an actor handle which was just created (during the call). We 
>> have to asynchronously deliver that constructor message before we 
>> deliver the RPC reply, in order for the content process to be aware of 
>> it.
>>
> 
> If ctors are the only reason we're using RPC, I say it's a semantic bug 
> that we should fix.  There are several ways we can special-case actor 
> ctors.  I'll file a bug.
> 

I see us using this in |PIFrameEmbedding::createWindow()|, but why can't 
that simply use the PIFrameEmbedding ctor?  Did I miss other usages?

Cheers,
Chris