Serializing NPAPI without plugin vendor cooperation

Some Mozilla content folks met today to discuss multi-process NPAPI. 
The consensus is that because we should expect to see today's plugin 
versions for the "foreseeable future" even if plugin vendors released 
new versions *today*, the short-term proposal for serializing NPAPI 
through NPN_PluginThreadAsyncCall is not worth pursuing.  We'll instead 
wait on the Google proposal 
(https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI) for a "real" 
solution to the problem, since the Google proposal is better in numerous 
respects.

So we're left to deal with the current situation.  We decided initially 
to follow chromium's approach and not provide atomicity guarantees to 
speak of.  Officially, (i) if a plugin calls an NPN_ function from a 
native event callback, it may be re-entered with a call to any NPP_ 
function; and (ii) no two sequential invocations of NPN_ functions are 
guaranteed to be atomic.  We'll have to see how well this works in 
practice.  bsmedberg is trying to reduce the number of cases when (i) 
occurs.

We also discussed ways to provide stronger atomicity guarantees without 
plugin vendor cooperation.  There are several ingredients we can add.

(0) Let the plugin always "win" non-NPRuntime race conditions as 
described in a previous thread.  This is hard for Gecko, and it only 
serves to reduce the number of races that would otherwise be handled by (1).

(1) Error on race conditions.  We can detect the browser calling into 
the plugin concurrently with the plugin calling into the browser with a 
very simple mechanism.  If a race occurs, we can return something like 
NPERR_RACE_CONDITION to both the browser and the plugin.  This applies 
to both NPRuntime and other NPAPI functions.  (We could alternatively 
kill off the plugin if this occurred.)  By error'ing in these 
conditions, we remove relaxation (i) above; that is, when there is no 
NPERR_RACE_CONDITION, then no NPN_ calls are re-entered any differently 
than they would be in the single-process, single-event-loop case.  In 
particular, this means plugin scripts retain run-to-completion semantics 
when there is no NPERR_RACE_CONDITION error.

(2) Provide "event loop atomicity" to the plugin.  That is, guarantee 
that all calls the plugin makes to NPN_* functions during each native 
event callback are atomic.  We can provide this (sanely) only if we can 
inject special events into the plugin's native event loop, on all 
platforms.  If this is possible, we remove relaxation (ii) above.

We can implement any or none of the "ingredients" above.  If we 
implement all of them, then in the absence of NPERR_RACE_CONDITION, 
NPAPI would remain serialized as it would be in the single-process, 
single-event-loop case.

Cheers,
Chris