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

On Fri, Apr 23, 2010 at 6:41 AM, Benjamin Smedberg
<[email protected]> wrote:
> On 4/23/10 8:13 AM, Mike Shaver wrote:
>>
>> On Fri, Apr 23, 2010 at 12:22 AM, Chris Jones<[email protected]>  wrote:
>>>  (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.

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?

Mike