Another reason to get rid of MessageLoop:
https://chromium-review.googlesource.com/1124692
When we call RunLoop::Quit() there's no way ThreadController may be aware of that immediatetely (before yielding DoWork).
So it forced us to use this nasty workaround:
void ThreadControllerImpl::DoWork() {
...
for (int i = 0; i < batch_size; i++) {
TakeTask();
RunTask();
DidRunTask();
if (nesting_depth > 0)
break;
}
...
}
So every time we're in a nested RunLoop we can't do a batch work because we have to pessimistically expect MessageLoop::Quit() anytime.
Implementing ThreadController and RunLoop::Delagate ourselves without the MessageLoop will help us to handle this case better.
Improvement suggestions list:
- Remove the entire SetDefault/RestoreDefault dance with ThreadController.
- Consider adding wake-up cancellation support for MessagePump.
- Make ThreadController interface as lean as possible.
- Support IO and UI MessagePumps.
Follow-up:
1. Can we cancel a previously scheduled wake-up with MessagePump?
2. MessagePump::DoDelayedWork(TimeTicks& next_delayed_work) doc says that setting next_delayed_work to null should indicate that the queue of delayed tasks is empty. So theoretically this can be used for timer cancellation. However, there's no such contract for ScheduleDelayedWork() method. I think we might want to harmonise APIs and contracts across various MessagePumps.
Comment 1 by kraynov@chromium.org
, Jul 3