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

On 4/23/10 8:13 AM, Mike Shaver wrote:
> On Fri, Apr 23, 2010 at 12:22 AM, Chris Jones<[email protected]>  wrote:
>>   (1) Forbid chrome from ever blocking on content, including forbidding 'rpc'
>> messages from content to chrome.  (And to be reiterate, 'sync' messages from
>> content to chrome would be perfectly acceptable.)
>>
>>   (2) Allow content-->chrome 'rpc', but audit all content code that might
>> reply to chrome-->content re-entry to ensure that it never computes
>> something the duration of which is controllable by web content.
>
> With (2), if the content process is busy with something like a reflow,
> it might block unacceptably before processing the "cheap" rpc reply
> path.  That's pretty much the source of the responsiveness issues we
> want to address with e10s for Fennec, after all.
>
> I think (1) is the right rule here.

Why?

This is about content->chrome RPC. We have *lots* of codepaths where content 
needs to block on chrome (alert()). The rule is that chrome must never block 
on content. But I do think we're going to need to use RPC messages in the 
other direction rather promiscuously, and I'm sure we're going to need RPC 
messages content->jetpack and jetpack->chrome, which amounts to pretty much 
the same thing.

--BDS