接下来分析 MessagePumpForUI
上一篇分析MessagePumpWin,可以参考chromium之message_pump_win之一
根据对MessagePumpWin的分析,MessagePumpForUI肯定要继承MessagePumpWin,且实现三个接口
// MessagePump methods: virtual void ScheduleWork(); virtual void ScheduleDelayedWork(const Time& delayed_work_time); virtual void DoRunLoop();
先看看介绍,有点长
//----------------------------------------------------------------------------- // MessagePumpForUI extends MessagePumpWin with methods that are particular to a // MessageLoop instantiated with TYPE_UI. // // MessagePumpForUI implements a "traditional" Windows message pump. It contains // a nearly infinite loop that peeks out messages, and then dispatches them. // Intermixed with those peeks are callouts to DoWork for pending tasks, and // DoDelayedWork for pending timers. When there are no events to be serviced, // this pump goes into a wait state. In most cases, this message pump handles // all processing. // // However, when a task, or windows event, invokes on the stack a native dialog // box or such, that window typically provides a bare bones (native?) message // pump. That bare-bones message pump generally supports little more than a // peek of the Windows message queue, followed by a dispatch of the peeked // message. MessageLoop extends that bare-bones message pump to also service // Tasks, at the cost of some complexity. // // The basic structure of the extension (refered to as a sub-pump) is that a // special message, kMsgHaveWork, is repeatedly injected into the Windows // Message queue. Each time the kMsgHaveWork message is peeked, checks are // made for an extended set of events, including the availability of Tasks to // run. // // After running a task, the special message kMsgHaveWork is again posted to // the Windows Message queue, ensuring a future time slice for processing a // future event. To prevent flooding the Windows Message queue, care is taken // to be sure that at most one kMsgHaveWork message is EVER pending in the // Window's Message queue. // // There are a few additional complexities in this system where, when there are // no Tasks to run, this otherwise infinite stream of messages which drives the // sub-pump is halted. The pump is automatically re-started when Tasks are // queued. // // A second complexity is that the presence of this stream of posted tasks may // prevent a bare-bones message pump from ever peeking a WM_PAINT or WM_TIMER. // Such paint and timer events always give priority to a posted message, such as // kMsgHaveWork messages. As a result, care is taken to do some peeking in // between the posting of each kMsgHaveWork message (i.e., after kMsgHaveWork // is peeked, and before a replacement kMsgHaveWork is posted). // // NOTE: Although it may seem odd that messages are used to start and stop this // flow (as opposed to signaling objects, etc.), it should be understood that // the native message pump will *only* respond to messages. As a result, it is // an excellent choice. It is also helpful that the starter messages that are // placed in the queue when new task arrive also awakens DoRunLoop. //