On Mon, Aug 17, 2009 at 11:43 AM, bsmedberg bsmedb...@gmail.com wrote:
At Mozilla we're currently working on implementing multi-process
plugin hosts similar to the model used by Chromium. However, we're
having trouble working through the many potential race conditions
introduced by having multiple processes (and therefore multiple flows
of control). I've read
http://dev.chromium.org/developers/design-documents/plugin-architecture
but that doesn't seem to address most of the issues we're facing.
For the detailed view of how we solve these issues, the best place to look
at is the code. Specifically, plugin_channel.cc ipc_sync_channel.cc.
To avoid deadlock, when one process is sending a synchronous message, it
responds to other synchronous messages in the meantime. However to avoid
unnecessary reentrancy, we disable this for synchronous messages from the
plugin process unless that process is itself responding to synchronous
messages. We did this because otherwise a plugin process could try to force
layout while it's already happening, which is not expected in WebKit. You
can find more about this in PluginChannel's constructor, we call
SendUnblockingOnlyDuringDispatch which makes it so that synchronous
The most obvious problem is that both processes may send a synchronous
IPC message at the same time. Assuming that these don't deadlock, the
native stack for the two calls would end up interleaved. What happens
when the renderer process and the plugin process send conflicting
messages at roughly the same time? For example: the browser finishes a
network request with NPP_DestroyStream and the plugin (responding to a
UI event, perhaps) calls NPN_DestroyStream simultaneously? I can't
imagine that a plugin would expect to receive aa NPP_DestroyStream
message after it has already called NPN_DestroyStream, and this is
likely to cause erratic plugin behavior.
This specific case is not really a problem. If you look at our
implementation of PluginInstance::NPP_DestroyStream(), we set NPStream.ndata
to NULL. The second call would early exit if it's already null.
Are the IPC delegates/stubs responsible for checking the state of each
call and avoiding improper nesting? Do you have any procedure/system
for detecting with racy improper nesting? For example, racing pairs
NPP_Write/NPN_DestroyStream and NPN_RequestRead/NPP_DestroyStream are
equally unexpected. And all these example come only from the NPStream
interface; I haven't even begun to examine potential message races in
the core NPP APIs or the NPObject APIs.
We did run into a bunch of these issues early on, but they were all easy to
workaround (i.e. always checking first if the stream is destroyed, since it
could be called afterwards in the situations that you describe).
The hardest issues we've had to solve are related to performance. The
initial release had poor performance when scrolling with lots of
windowed/windowless plugins. To solve this, we moved to an asynchronous
painting/scrolling model. While adding extra complexity and memory usage,
the user experience when scrolling is much better. The techniques we used
should be applicable in your implementation as well, we can talk more about
this when you're ready (plugin lunch? :) ).
--BDS
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
