对比一下Boost::Asio和SP_Server的实现

Boost::Asio的异步操作和本版iunknown的SP_Server，在本质上都属于用Reactor来模拟Proactor实现，其基本原理是一样的，就是将Reactor中的IO就绪事件封装成为IO完成事件。
sp_server基于libevent，它的工作原理是：libevent不断抛出io就绪事件，由sp_server负责处理io之后，再封装好io完成事件，然后将处理该事件的completion handler（完成事件，就是在IO处理完成之后需要进行的操作，由用户指定）放入queue中，随后由运行server的主线程从queue中取出，并根据不同的线程池策略来运行该handler。
asio也是类似，工作过程是：io_service封装了reactor,用户必须执行io_service::run()来确保proactor能够运行。reactor处理io事件，完成之后将completion handler放入io_service的queue中等待调度。所不同的是，由于reactor在io_service，也就是proactor中运行，因此reactor的io队列，和proactor的handler队列，尽管逻辑上跟sp_server一样是完全分开的，但是它们均运行在同样的上下文中。当采用线程池来绑定asio时，只能对io_service::run()做统一调度，这就是说，可能会有不同的线程来进行io处理，而另外不同的线程来处理completion handler，这无形中会增加线程切换的代价，而sp_server则确保了只有主线程进行io处理，线程池负责任务处理。

我认为：
asio中多个线程去抢io_service::run()运行在多核的CPU上是能带来更好的效果的。
asio里面的win_iocp_io_service.hpp可是用的完成端口哦，是原生的proactor。
但是posix下面的aio系列函数不能对socket描述符进行操作，所以只能用epoll，kqueue，select等等去模拟proactor出来。

多个线程去抢的这种模型，应该就是 leader/follower 模型。
SPServer 支持 Half-Async/Half-Sync 和 leader/follower 两种模型。
LZ 提到 SPServer 说的应该是 Half-Async/Half-Sync 模型。
实际测试过两种模型，Leader/Follower 模型的确比 Half-Async/Half-Sync 模型快。

不过楼上的，我们说的不是一个事情哦