Update ioloop.cpp

[starrybeam]

如果当前没有超时的timer，下一个即将超时的timer是500ms，此前的短代码需要等待1000ms

[chenneal]

哈哈，我之前我也发现了这个问题，但是仔细考虑了一下，似乎觉得并不需要那么严格，理由如下：

我认为这里的timeout并不是严格定义的，楼主觉得有问题，应该主要是在下面这个函数判断里：

    bool peek(T& t, int timeoutMS) {
        while (empty()) {
            // 这里做了个超时判断，等待的时间不能超过即将超时的时间。
            if (_cond.wait_for(_lock, std::chrono::milliseconds(timeoutMS)) == \
               std::cv_status::timeout) {
                return false;
            }
        }
        t = _storage.front();
        return true;
    }

这里使用了timeout最为最大等待时长的依据，假设博主说下一个nexttimeout是500ms，但是这时候由于误判变成1000ms，那么可能会使得原本可以及时处理的消息变成超时消息。但是我觉得即使正确判断了nexttimeout是500ms，仍然可能会超时。因为假使我等待_cond.wait_for()花了400ms，但是处理消息也需要花时间，一旦处理事件超过100ms仍旧会超时，从代码上看消息处理时间是没有进行计算的。

综上，我觉得这个timeout只是一个预估的值，用来尽可能及时的处理消息，但是并不是严格要求及时性。楼主的修改可以更精确地判断“及时”的准确性，但是效果能有多少很难说。

个人之见，可能有误，望指出，也希望得到作者的回复。

[lynncui00]

这里定时器和ioloop处理的正常消息是协同工作，不可分割的。什么是协同工作？意思就是定时器的产生源是来自于正常处理的消息，所以当定时器处理完所有的定时事件之后，在处理正常消息之前是不会有新的定时事件产生的，可以理解为定时器的生产和消费是在同一个线程上的。而你似乎要解决的问题是支持跨线程的纯定时器问题？这个完全则是另外一个问题了。