Re: Plugin threading model in Electrolysis

On 8/17/09 1:00 PM, Chris Jones wrote:

> First, in the multi-process case it might be possible for us to
> explicitly serialize plugin event processing with browser event
> processing through a bit of hackery.  If we can override the native
> event registration functions, then we can instead register our own shim

As noted on IRC, we probably can't override the native event registration
functions because plugins can create arbitrary windows that we know nothing
about (fullscreen mode, dialogs, etc).

The proposal later using NPN_PluginThreadAsyncCall to explicitly serialize
the world sounds reasonable, although I think it may not fit in with
existing plugin architecture. Another possibility (which would involve new
APIs) is a pair of functions which can be called at any point to safely
start rpc-threading the two processes:

NPN_StartRunToCompletion
NPN_EndRunToCompletion

> A second option is to keep the two threads of control, but bullet-proof
> the browser process against all possible race conditions.  bsmedberg

I think that this is the option we will have to go with for now, at least in
a limited form. So far, all of the races I have found are fairly easy to
detect and deal with:

races of stream functions against an already-closed stream
races of plugin functions against an already-closed plugin instance

Unfortunately I don't think this is something that IPDL has the ability to
deal with, since the behavior (return value/etc) of calling a method on a
closed stream is different for each function.

I don't think that there are any races with NPOBject, since those are
refcounted and don't have explicit destructors.

--BDS