MFC全接触（三）

       昨天"问题男"老大给我的那篇post：噢，我的第一个基于SDK的窗口写了回复：“为何要PeekMessage呢？这样会令你的程序占用能占用的所有cpu时间，不如GetMessage，在没有消息时线程将被suspend。”这个回复让我思考了很久，也让我有了更多收获。真的很喜欢这种感觉，自己写下了一些简单而不成熟的想法，高手看到了又不吝赐教，正是大家这种知识共享的精神让我每天都有莫大的收获，真的很感谢！有点跑题了，呵呵~~
        说实在的，当时在运行自己写的例子的时候，确实发现CPU时间被耗尽了，系统运行得很慢，当时还真的没有反应过来是怎么回事，而且由于当时关注的问题并不在此，也没有去多想，只是想着随后要看一下基于MFC的程序运行会不会也是占用那么多的CPU时间(虽然当时我就知道答案肯定是不会的，呵呵)。直至看到了以上回复的时候，脑袋瓜受到了激发，一些原先完全割裂开的认识被这个回复联系到了一起。
        首先，刚开始接触PeekMessage和GetMessage的时候，文档告诉我PeekMessage是一个具有线程异步行为的函数，不管消息队列中是否有消息的，函数都会立即返回。而GetMessage则是一个具有线程同步行为的函数，如果消息队列中没有消息的话，函数就会一直等待，直到消息队列中至少有一条消息的时候，才会返回。先不管线程同步或者异步的话题，光看PeekMessage无论什么情况下都会返回，就会知道例子中的消息处理代码在消息队列中没有消息的时候，会不断的循环执行，就相当一个死循环，CPU不耗尽才怪呢。
        其次，正是"问题男"老大的回复让我想起了MFC中的消息处理机制：在那里不也用了PeekMessage函数到消息队列中取消息吗？那她到底是怎样避免死循环的出现的呢？于是，我再次回到CWinThread类中的Run函数中去看个究竟：

for  (;;)
{
    // phase1: check to see if we can do idle work
    while (bIdle &&!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))
    {
        // call OnIdle while in bIdle state
    if (!OnIdle(lIdleCount++))
        bIdle = FALSE; // assume "no idle" state
    }

    // phase2: pump messages while available
    do
    {
        // pump message, but quit on WM_QUIT
    if (!PumpMessage())
        return ExitInstance();

    // reset "no idle" state after pumping "normal" message
    if (IsIdleMessage(&m_msgCur))
    {
        bIdle = TRUE;
        lIdleCount = 0;
    }

    } while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));
}     

        代码中的bIdle的初始值是TRUE，如果PeekMessage返回值为FALSE，也就是当队列中没有消息的时候，那么while中的整个条件语句为TRUE，就会去调用OnIdle函数。由于lIdleCountOnIdle作为OnIdle函数的入参，且初始值为0，而返回的语句则是return lCount < 0，也就是说OnIdle返回值肯定是FALSE，那么bIdle就被赋值为FALSE了，自然就跳出了循环。接着就再进入下一个循环，通过PumpMessage方法去取得消息，而PumpMessage中实质就是调用了GetMessage方法去获得消息。总之在两个循环当中，PeekMessage的作用就象是探路石一样，去check一下队列中的是否有消息，有的话，是怎样的消息，但是她并没有将消息从队列中移除，我们可以通过PeekMessage方法中的最后一个参数就可以看出了。同时，两个循环也是交替进行的，象第二个循环，当消息队列中没有消息的时候，也会再一次回到一个循环。MFC之所以这样设计是希望能够通过OnIdle方法去处理当该窗体所属的线程处于空闲状态的情况，同时也保证了线程不会因为GetMessage而进入休眠状态。