We should create an isolated settings service, extracting from src/chrome. It needs to support everything the Preferences code in Chrome does, including enterprise policy management, sync & extensions APIs. It must not depend on anything from src/chrome, only other //services.
Hey, so I landed a revert of the IO thread startup in #18
What is happening is that there is a race inherent to the startup of the chrome and ash services.
wm_shell attempts to connect to preferences
chrome instantiates the preferences service.
The change delayed the creation of the service handler until later on the io_thread. Leading to a race.
We might need to have the handlers created at the request time, with their work posted to the io thread.
Thoughts?
Should bug 125840 be duped into this? Does it track things this bug does not?
AFAICT, PrefService is not a keyed service today. I have a bug about a TODO I wrote where, when PrefService becomes a keyed service, some particular code should DependsOn() it. What should I do with that bug -- update it to block on this and change the summary and TODO to something different, or close it and remove the TODO from the code?
On a Nexus 9 with tracing enabled, service manager and its client library were taking ~60ms to start the pref service and establish 6 connections via BindInterface. Establishing only 3 connections dropped it to ~40ms. As context, initializing prefs without the pref service takes ~10ms.
A good chunk of the time seemed to be spent copying, serializing or deserializing service_manager::InterfaceProviderSpecMap.
In the mean time r468553 seems to have removed one of the serialize/deserialize pairs.
Components: Internals>Preferences>Service Summary: Extract Preferences into a service (was: Content Modularization Project: Extract Preferences into a service)
Cc: roc...@chromium.org jam@chromium.org Owner: sa...@chromium.org Status: Started (was: Fixed) Summary: Expose Preferences from the browser process as a service (was: Extract Preferences into a service)
As discussed in the meeting with jam@ and rockot@, the memory impact of adding an extra copy of prefs is too high so we're going to not treat prefs as a service from inside the browser process. https://chromium-review.googlesource.com/c/554653/ is how this is likely to end up looking.
There's still an open question of whether services should use a sync API with an extra local copy of just the prefs they use or whether they should migrate to an async API when turning into a service.
Comment 1 Deleted