Re: Plugin threading model in Electrolysis

I don't understand NPAPI guts well enough to help much here, but from  
a security standpoint I'd recommend a model thats as deterministic and  
reliable as possible.  The second proposal scares me too as it  
requires some really clever consumption of the event queue, and the  
heartbeat approach of #3 is also a bit scary insofar you might be  
introducing race conditions where the container and plugin security  
contexts get out of synch in between heartbeats.  So I'm in  
tentatively in favor of #1.
   Lucas.

On Aug 17, 2009, at 10:00 AM, Chris Jones wrote:

> AIUI, the current NPAPI threading model has one thread of control,  
> the browser's.  NPP (plugin) functions can be invoked in one of two  
> ways: browser code explicitly calling one, or for windowed plugins,  
> the native event loop invoking a plugin's event callback on the  
> browser thread.  In both cases all NPAPI function calls are serial.
>
> For the multi-process case, we're proposing to let plugins handle  
> native events in their own thread of control, in the plugin  
> process.  This processing would happen concurrently with the  
> browser's thread of control, in the parent process.  On the surface  
> this breaks the NPAPI threading model.  It's probably worth  
> discussing the implications of this.
>
> 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 handlers that queue events on which the plugin's handler will  
> later be invoked.  "Later" would mean "when the browser sends a  
> message that transfers the execution context to the plugin."  This  
> isn't a great solution, but it's conservative.  Another way to  
> achieve this goal is to have the parent process somehow intercept  
> events destined for the child process, and the parent only deliver  
> those events when it's ready.
>
> A second option is to keep the two threads of control, but bullet- 
> proof the browser process against all possible race conditions.   
> bsmedberg pointed out one such in the previous thread.  This sounds  
> scary to me, but we presumably need to do something similar at the  
> moment anyway. For example, in the single-threaded case, if the  
> plugin receives a native event that causes it to call  
> "NPN_DestroyStream()", and the next browser event is a network event  
> that we would like to deliver to the stream, the browser would need  
> to realize that the stream had been closed anyway.  Any NPAPI  
> experts care to comment on the feasibility of this approach?
>
> I can't think of any other options short of changing NPAPI.  Can  
> anyone else?
>
> Cheers,
> Chris
> _______________________________________________
> dev-tech-dom mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-dom