gecko-dev/devtools/server/tests
Gijs Kruitbosch ea58459bc1 Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley
Finally, let's move the actual IO away from the main thread.

This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
   on the main thread.
2. loading plugins from LoadPlugins. This will:
   a) first check prefs and report the flash plugin based on that information,
      if the prefs indicate it exists (using the callback provided by
      nsPluginHost).
   b) then hopefully dispatch to a background thread, where it will read
      pluginreg.dat, scan the appropriate folders on disk, and see if
      anything changed. Once done, it sets mFinishedFinding to true and
      re-dispatches itself to the main thread.
   c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
   thread.

Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.

In order for this to work, there are some other changes in this commit:

- the sandbox prefs are being read "early" and cached for flash vs
  "everything else". We can't access prefs on non-main threads without
  using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
  This is a bit unfortunate, but because they're instantiated on a non-
  mainthread, and then later used on the main thread, despite the
  fact that the architecture means nothing tries to touch them from
  more than one thread at once, without threadsafe refcounting we hit
  asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
  be halfway through finding plugins and then trying to shut them down,
  or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
  doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
  trying to write to pluginreg while we're reading it somewhere else,
  etc. If there's an attempt to do more plugin finding while this is
  ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
  our initial lookups are complete.

Depends on D48331

Differential Revision: https://phabricator.services.mozilla.com/D48332

--HG--
extra : moz-landing-system : lando
2019-11-02 22:35:04 +00:00
..
browser Bug 1582531 - Update fission annotations for tests that fail cleanly, r=mccr8 2019-10-30 21:51:35 +00:00
mochitest Bug 1094939 - Preferences actor should throw with the name for an unknown preference. r=ochameau 2019-10-31 14:05:46 +00:00
unit Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley 2019-11-02 22:35:04 +00:00