Chris Jones
2010-04-23 07:22:43 UTC
tl;dr
o The biggest win for e10s on mobile is UI perceived responsiveness
o We lose that if chrome can block on content
o There's perhaps been some confusion about reentrant vs.
non-reentrant synchronous messaging
- non-reentrant synchronous messaging is perfectly OK content-->chrome
- reentrant is not, because it potentially blocks chrome on content
o Therefore, abolish chrome blocking on content, including reentrant
synchronous messages from content-->chrome
o (Jetpacks and debuggers are not being discussed)
(Spawned off from jduell's post in m.d.t.dom. I think we should discuss
the "what" before the "how".)
Let's start from first principles: we want e10s for mobile Firefox
mainly because by running chrome and content code in separate processes,
the chrome UI can stay responsive even if content isn't. e10s achieves
this by giving chrome and content separate event loops. Chrome can
process input events in its event loop without being delayed by content.
We might even be able to put a rough upper bound on how long chrome
takes before responding to arbitrary input; in fact, establishing and
minimizing such an upper bound should be an explicit goal IMHO.
We lose this improved responsiveness if the processing of events in the
chrome event loop can be delayed by web content. One way this can
happen if chrome makes a synchronous request to content, i.e. blocks on
content. AFAIK, no one advocates this.
There's a second way that has recently arisen. To discuss it, some
background is required. Our IPC mechanisms support three messaging
models between A and B
o 'async' --- A "fires and forgets" a message to B. Neither A blocks
on B nor B blocks on A.
o 'sync' --- A sends a non-reentrant, synchronous message to B. This
means A blocks on B until B replies to the message. However, while
replying to the message, B is not allowed to "re-enter" A, that is, send
a synchronous message to A. From A's perspective, sending the message
and receiving the reply is synchronous. But from B's perspective,
replying to the message is asynchronous.
o 'rpc' --- A sends a reentrant, synchronous message to B. This means
that while B replies to A, it is allowed to "re-enter" A with a
synchronous message. (And A can further re-enter B, and so forth.)
(This is sort of how function calls work, hence the name 'rpc', "remote
procedure call".)
So with that, the second way chrome can block on content is if content
is allowed to send an 'rpc' message to chrome. This would mean that,
while replying to content, chrome code could send back an 'rpc' message,
re-entering content and blocking on it. Once chrome re-enters content
in this way, it's at the mercy of content code to not invoke web content
directly or compute values parameterized by web content. If it did,
then chrome could block arbitrarily on content, and responsiveness loses.
So I think we have two paths going forward
(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.
It seems to me that (1) is the path more likely to end in victory. That
said, it won't be easy, and things will break.
A compelling counterargument to (1) could take the form of, "If we can't
'rpc' from content to chrome, there's no possible way to implement
killer feature X."
And to be clear, this manifesto *does not* cover Jetpacks or debuggers:
they are separate problems. I don't know how current add-ons fit in
(debuggers excluded), but I also don't know that that's a problem we
need to solve fully before releasing fennec+electrolysis.
Cheers,
Chris
o The biggest win for e10s on mobile is UI perceived responsiveness
o We lose that if chrome can block on content
o There's perhaps been some confusion about reentrant vs.
non-reentrant synchronous messaging
- non-reentrant synchronous messaging is perfectly OK content-->chrome
- reentrant is not, because it potentially blocks chrome on content
o Therefore, abolish chrome blocking on content, including reentrant
synchronous messages from content-->chrome
o (Jetpacks and debuggers are not being discussed)
(Spawned off from jduell's post in m.d.t.dom. I think we should discuss
the "what" before the "how".)
Let's start from first principles: we want e10s for mobile Firefox
mainly because by running chrome and content code in separate processes,
the chrome UI can stay responsive even if content isn't. e10s achieves
this by giving chrome and content separate event loops. Chrome can
process input events in its event loop without being delayed by content.
We might even be able to put a rough upper bound on how long chrome
takes before responding to arbitrary input; in fact, establishing and
minimizing such an upper bound should be an explicit goal IMHO.
We lose this improved responsiveness if the processing of events in the
chrome event loop can be delayed by web content. One way this can
happen if chrome makes a synchronous request to content, i.e. blocks on
content. AFAIK, no one advocates this.
There's a second way that has recently arisen. To discuss it, some
background is required. Our IPC mechanisms support three messaging
models between A and B
o 'async' --- A "fires and forgets" a message to B. Neither A blocks
on B nor B blocks on A.
o 'sync' --- A sends a non-reentrant, synchronous message to B. This
means A blocks on B until B replies to the message. However, while
replying to the message, B is not allowed to "re-enter" A, that is, send
a synchronous message to A. From A's perspective, sending the message
and receiving the reply is synchronous. But from B's perspective,
replying to the message is asynchronous.
o 'rpc' --- A sends a reentrant, synchronous message to B. This means
that while B replies to A, it is allowed to "re-enter" A with a
synchronous message. (And A can further re-enter B, and so forth.)
(This is sort of how function calls work, hence the name 'rpc', "remote
procedure call".)
So with that, the second way chrome can block on content is if content
is allowed to send an 'rpc' message to chrome. This would mean that,
while replying to content, chrome code could send back an 'rpc' message,
re-entering content and blocking on it. Once chrome re-enters content
in this way, it's at the mercy of content code to not invoke web content
directly or compute values parameterized by web content. If it did,
then chrome could block arbitrarily on content, and responsiveness loses.
So I think we have two paths going forward
(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.
It seems to me that (1) is the path more likely to end in victory. That
said, it won't be easy, and things will break.
A compelling counterargument to (1) could take the form of, "If we can't
'rpc' from content to chrome, there's no possible way to implement
killer feature X."
And to be clear, this manifesto *does not* cover Jetpacks or debuggers:
they are separate problems. I don't know how current add-ons fit in
(debuggers excluded), but I also don't know that that's a problem we
need to solve fully before releasing fennec+electrolysis.
Cheers,
Chris