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