另外，多线程这块是否可以考虑引进chrome的线程模型，用命令模式做一个循环，分别支持UI线程，普通工作线程。如果io都支持fiber，那么chrome的io线程的消息泵就不需要了。目前c++11提供的lambda表达式std::function和bind可以较为容易实现，结合引用计数和弱指针。这样做，使用者几乎可以不用考虑锁的问题，线程内部使用协程io，跨线程通信只需要按照命令模式posttask。

我们项目使用了ACL的一些工具，例如redis客户端。这几天我在看acl的fiber实现原理。目前win32网络通信的API都hook了，但是overlapped方式进行本地io没hook，这有点小遗憾。

另外，多线程这块是否可以考虑引进chrome的线程模型，用命令模式做一个循环，分别支持UI线程，普通工作线程。如果io都支持fiber，那么chrome的io线程的消息泵就不需要了。目前c++11提供的lambda表达式std::function和bind可以较为容易实现，结合引用计数和弱指针。这样做，使用者几乎可以不用考虑锁的问题，线程内部使用协程io，跨线程通信只需要按照命令模式posttask。

我查看了chrome的消息泵：

我们项目使用了ACL的一些工具，例如redis客户端。这几天我在看acl的fiber实现原理。目前win32网络通信的API都hook了，但是overlapped方式进行本地io没hook，这有点小遗憾。

我查看了chrome的消息泵：

```

void MessagePumpDefault::Run(Delegate *delegate) {

for (;;) {

bool did_work = delegate->DoWork();

if (false == keep_running_)

break;

did_work |= delegate->DoDelayedWork(&delayed_work_time_);

if (false == keep_running_)

break;

if (did_work)

continue;

did_work = delegate->DoIdleWork();

if (false == keep_running_)

break;

if (did_work)

continue;

if (delayed_work_time_.is_null()) {

event_.Wait();

} else {

TimeDelta delay = delayed_work_time_ - TimeTicks::Now();

if (delay > TimeDelta()) {

event_.TimedWait(delay);

} else {

// It looks like delayed_work_time_ indicates a time in the past, so we

// need to call DoDelayedWork now.

delayed_work_time_ = TimeTicks();

}

}

}

keep_running_ = true;

}

```

在这个消息泵里面，增加一个从epoll/iocp取异步结果进行回调的步骤，以驱动协程体系。这样所有的异步io都能够以同步方式呈现，跨线程使用命令模式通信，几乎完全不需要锁了。