gecko-dev/toolkit/mozapps
Gijs Kruitbosch dc78268f2e 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-10-30 15:53:15 +00:00
..
downloads Bug 1578683 Turn on ESLint rule prefer-boolean-length-check for toolkit and browser r=Standard8 2019-09-14 09:39:26 +00:00
extensions Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley 2019-10-30 15:53:15 +00:00
handling Backed out 6 changesets (bug 1553804) for browser-chrome failure at browser/base/content/test/general/browser_fullscreen-window-open.js. On a CLOSED TREE 2019-09-20 10:09:54 +03:00
installer Bug 1485057: Fix makensis.mk to allow helper.exe to build incrementally; r=mshal 2019-10-24 23:49:56 +00:00
preferences Bug 1578683 Turn on ESLint rule prefer-boolean-length-check for toolkit and browser r=Standard8 2019-09-14 09:39:26 +00:00
update Bug 1592083 - Convert certList to raw array for nsITransportSecurityInfo r=keeler,Ehsan,kershaw 2019-10-29 17:20:07 +00:00