[MessageLoop] MessageLoopTaskRunner as multi-threaded incoming queue.
Introduces the SequencedTaskSource interface to //base. This should ultimately be coalesced with a similar interface used by SequenceManager but this CL was complex enough in isolation that it was easier to introduce only the basic API for now. MessageLoop will as a follow-up expose an API that will allow it to be created with a custom SequencedTaskSource. This will enable ScopedTaskEnvironment::MOCK_TIME on custom MessageLoops (i.e. ForUI/ForIO) and soon after on all threads (not just main thread), since TaskScheduler's delayed tasks are managed on a MessageLoopForIO. Finally this will allow MOCK_TIME on TestBrowserThreadBundle (which uses a MessageLoopForUI); nicely rounding out the MOCK_TIME APIs. In this CL the following semantics have changed in MessageLoop : * MessageLoop::unbound_task_runner_ -> - MessageLoop::underlying_task_runner_ - MessageLoop::task_runner_ still initially set to it - but now const to clarify lifetime (and not set to null in ~MessageLoop() as this was pointless) - Implements SequencedTaskSource - Now has a Shutdown() phase so that PostTask() that happen-after ~MessageLoop() returns false (MessageLoop::Controller::DisconnectFromParent() still required, see comment in ~MessageLoop()) * IncomingTaskQueue (to be renamed to PendingTaskQueue in follow-up) : - no longer has a TriageQueue (MessageLoop communicates directly with SequencedTaskSource) - no longer ref-counted, strictly a member of MessageLoop - MessageLoop uses it as storage for tasks it must delay/defer - IncomingTaskQueue no longer has a Shutdown() phase, becomes dead storage on shutdown and dies with MessageLoop - Racy PostTask() on shutdown are now strictly handled between MessageLoop and its Controller * SequencedTaskSource : - the interface MessageLoop feeds from, initially only implemented by MessageLoopTaskRunner but will be made customizable as a follow-up * MessageLoop::SetTaskRunner() - still a thing to keep existing use cases alive but will ultimately die in favor of providing an external SequencedTaskSource (and killing all MessageLoop task_runner dances performed today :)) Note: most new logic in message_loop_task_runner.cc was moved as-is from incoming_task_queue.cc Bug: 708584, 860252 Change-Id: I23f40d293d2df6fe41374fad127745f2ff72fbe0 Reviewed-on: https://chromium-review.googlesource.com/1088762 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by:kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#578809}
Showing
This diff is collapsed.
Please register or sign in to comment