Experiment with redirecting all BrowserThreads (but UI/IO) to TaskScheduler
This is part of the migration phase for TaskScheduler, design doc: https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa5k/edit Also generalizes BrowserThreadImpl away from the underlying thread's MessageLoop and id in favor of TaskRunners and BrowserThreadState. Cool side-effect: BrowserThreadImpl::StartWithOptions() no longer blocks on the underlying thread starting (it used to via GetThreadId()), it now takes a reference to its TaskRunner and lets the thread itself start on its own schedule :). This wasn't previously intended to block (BrowserThreadImpl::StartAndWaitForTesting() is supposed to be used for that) but had unintentionally regressed in http://crrev.com/408295 because GetThreadId() implicitly waits (http://crbug.com/672977). Another nice improvement is that ~BrowserThreadImpl() now cleans the BrowserThreadGlobals associated with it, this has the side-effect to force proper destruction order of TestBrowserThread in tests which brought forth a few precursor cleanups (https://crbug.com/653916#c24) which will from now on be enforced by this CL. When redirection is disabled, the logic should be the exact same as before. - Threads are brought up. - Tasks are posted to their MessageLoop (albeit through their TaskRunner now). - On shutdown, threads are joined one by one. When redirection is enabled, we try to mimic this logic. - Redirection TaskRunners are only live (|accepting_tasks|) for the same period that the matching thread would be. - On shutdown, we block on each TaskRunner's queue being flushed one-by-one in the same order as in the no-redirection case (this almost identical to real threads join % one slight difference documented in detail in BrowserThreadImpl::StopRedirectionOfThreadID()). BUG=653916, 672977 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_tsan_rel_ng TEST= A) "out\Release\chrome.exe" Runs/shuts down the exact same as before. B) "out\Release\chrome.exe --force-fieldtrials=BrowserScheduler/Enabled/ --force-fieldtrial-params=BrowserScheduler.Enabled:Background/3;3;1;0;10000/BackgroundFileIO/3;3;1;0;10000/Foreground/3;3;1;0;10000/ForegroundFileIO/3;3;1;0;10000/RedirectSequencedWorkerPools/true/RedirectNonUINonIOBrowserThreads/true" Runs/shuts down smoothly and chrome://tracing confirms that redirected BrowserThreads are running on TaskSchedulerWorkers. Review-Url: https://codereview.chromium.org/2464233002 Cr-Commit-Position: refs/heads/master@{#439139}
Showing
This diff is collapsed.
This diff is collapsed.
Please register or sign in to comment