Plugin threading model in Electrolysis

Chris Jones <[email protected]>
Newsgroups gmane.comp.mozilla.devel.dom
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.