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