Make creation of ProxyConfigService less awful |
|||
Issue descriptionRight now ProxyConfigService has to be created on the UI thread, because ProxyConfigServiceLinux uses gconf/gsettings, and glib has thread affinity. This makes it fairly unique among other network dependencies which are born and die on the IO thead. This weirdness has trickled down and added complexity in a number of areas. Seeing how terrible this has become, I wonder if it wouldn't be preferable to just pass the magical Linux dependency via a global. i.e. #if .... ProxyConfigServiceLinux::SetGlibTaskRunner(...) #endif Then the code can just live on the IO thread. Embedders on Linux would be responsible for setting that dependency.
,
Jun 22 2017
I'm thinking we may move the PorxyConfigService over to the UIThread, anyways, for the network service stuff. Alternatively, we could make an API to override it, and completely rewrite how ProxyConfigTrackerImpl to use that instead....But then if we're running it in the network process, what thread is the GTK thread? Is that just the main thread, which makes this moot, at least for Chrome, anyways?
,
Jun 22 2017
Don't know the details, but there is some explicit initialization needed for the thread. Not sure whether that can run in the sandboxed process.
,
Nov 29 2017
Given the changes Matt has made for servicification this bug is no longer accurate. @mmenke: want to close this? ProxyConfigServiceLinux is still bad, but that is somewhat of a separate concern...
,
Nov 29 2017
SGTM. |
|||
►
Sign in to add a comment |
|||
Comment 1 by eroman@chromium.org
, Jun 22 2017