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.
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.
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.
--BDS
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
