Re: Plugin threading model in Electrolysis

Chris Jones <[email protected]>
Newsgroups gmane.comp.mozilla.devel.dom
Message-ID <[email protected]>
Chris Jones wrote:
> I can't think of any other options short of changing NPAPI.  Can anyone 
> else?
> 

Another option is to serialize messages by always letting the plugin 
process always "win."  That is, when the plugin sends a message to the 
browser, the browser processes it immediately, as it normally would.

However, when the browser wants to send a message to the plugin, the 
message goes into a special queue, before it's had a chance to be 
delivered to any code in the browser that might potentially cause side 
effects wrt NPAPI.  The message is only sent to the plugin at explicit 
"rendezvous" points, when the plugin explicitly tells the browser "I'm 
ready to receive messages."

We can implement the rendezvous by creating a heartbeat timer in the 
plugin process that fires at X Hz (X might be 120).  When that timer 
fires, we know that the plugin is idle and ready to receive messages. 
So the timer callback sends a Rendezvous() message to the browser, and 
if the browser has outstanding events in its queue, it processes them 
normally.  Otherwise, the browser responds to the Rendezvous() 
immediately, and the rendezvous is a no-op.

The difficulty with this proposal is sanely queuing 
NPAPI-side-effect-causing events.  We'd either have to do this with 
special event callbacks, e.g. in an OnDataAvailable() callback for an 
NPStream, which should work if possible, or at points where Gecko code 
enters NPAPI code.  The former approach appears to be nearly impossible. 
  For the latter approach, we'd need to spin up a nested event loop in 
the browser until it received the Rendezvous() from the plugin.  The 
latter approach has the added disadvantage of potentially executing 
side-effect-causing code in the browser before we spin the nested loop, 
which means that if the plugin sends a message to the browser after the 
browser has reached the nested event loop, we still might have problems 
above the NPAPI level.

A completely separate approach is to rewrite the Gecko and NPAPI code on 
the browser side to be asynchronous wrt to NPAPI.  In theory this would 
work, but is a big project and may be impossible in practice because of 
broken assumptions throughout Gecko (i.e., it may end up being a 
near-complete Gecko rewrite).

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.