Re: Plugin threading model in Electrolysis

Benjamin Smedberg wrote:
> 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).
> 

Yeah, we'd need to hook event handlers at the platform-API or event 
delivery level.

> 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.

Why do you say that?

> 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
> 

The implementation of this sounds scarier to me than that for 
NPN_PluginThreadAsyncCall, and this additionally requires extending 
NPAPI.  I guess we'll have to let plugin vendors comment on this.

>> 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
> 

Just to clarify based on our IRC conversation, pretty much all of 
NPP/NPN can race.  These are the functions you've so far identified for 
which the race might produce "unexpected" effects.

> 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.
> 

Yeah, I agree.  The NPAPI "protocol" has to define these as racy.  The 
only thing we could do in IPDL is kill off the child if RPC races, which 
I think is sensible, but may not meet with general approval.

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

I assume you mean no races for destroying NPObjects?

Cheers,
Chris