Various implementations of PasswordStore use different types of background task runners:
* Most of them (Win, CrOS, Linux without Gnome Keyring, Android and iOS) can just use base::CreateSequencedTaskRunnerWithTraits({base::MayBlock(), base::TaskPriority::USER_VISIBLE}).
* Linux with Gnome Keyring needs Wait() allowed ( bug 739897 ), resulting in the additional trait base::WithBaseSyncPrimitives(). This task runner is already available before constructing the base PasswordStore.
* Mac creates a special base::Thread to run background operations on. This happens during PasswordStoreMac::Init, and is not available during construction of the base PasswordStore.
Because the base PasswordStore also needs the background task runner, it needs it to be provided by the inheriting class. This happens currently by overriding PasswordStore::GetBackgroundTaskRunner, or alternatively by passing the task runner to PasswordStore through PasswordStoreDefault as a constructor argument (obviously does not work for Mac). The base implementation of PasswordStore::GetBackgroundTaskRunner returns whatever was passed to the constructor.
Based on the recommendation in https://chromium.googlesource.com/chromium/src/+/master/docs/task_scheduler_migration.md#BrowserThreads, we should move TaskRunner creation as much inside (near the base PasswordStore) as possible. So the steps to take are:
(1) Verify whether PasswordStoreMac really needs a dedicated thread.
(2) Change the API from allowing two ways of repeatedly changing the background task runner (overriding GetBackgroundTaskRunner any time + passing the constructor argument once) to a single, one-off way: likely passing creating options to PasswordStore::Init and letting it construct the correct task runner; further, PasswordStore::GetBackgroundTaskRunner should become non-virtual (and likely just a light background_task_runner() accessor).
This would be better done once the migration of PasswordStore off the DB thread is done.
Comment 1 by vabr@chromium.org
, Jul 12 2017