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

Benjamin Smedberg wrote:
> On 4/23/10 10:14 AM, Mike Shaver wrote:
> 
>> What does "reply to chrome->content re-entry" mean, then, and why do
>> we care if it computes something for which the duration is
>> controllable by web content?
> 
> I think cjones is incorrect about chrome->content re-entery with RPC 
> messages, because we don't allow RPC messages in that direction.

Incorrect how?  All I'm saying is we shouldn't be doing this, and we 
have new protocols that do, but see below.

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

Cheers,
Chris