系统I/O 可分为阻塞型, 非阻塞同步型，非阻塞异步型。 （Linux对aio支持的不完整，所以linux上用Reactor比较多；Proactor需要系统API支持真正的“异步”）
阻塞型I/O意味着控制权直到调用操作结束才会返回到调用者手里。因此调用者被阻塞了, 这段时间了做不了任何其它事情. 更郁闷的是,在等待IO结果的时间里,调用者所在线程此时无法腾出手来去响应其它的请求。拿read()操作来说吧, 调用此函数的代码会一直僵在此处直至它所读的socket缓存中有数据到来.
相比之下，非阻塞同步是会立即返回控制权给调用者的。调用者不需要等等，它从调用的函数获取两种结果：要么此次调用成功进行了；要么系统返回错误标识告诉调用者当前资源不可用，你再等等或者再试度看吧。比如一个read()操作对sockect在非阻塞模式下，返回成功读取的字节数，或者失败返回特殊码-1设置为EWOULBLOCK/EAGAIN，告诉调用read()者"数据还没准备好，你稍后再试".
在非阻塞异步调用中，稍有不同。调用函数在立即返回时，还告诉调用者，这次请求已经开始了。系统会使用另外的资源或者线程来完成这次调用操作，并在完成的时候知会调用者（比如通过回调函数）。拿Windows的ReadFile()或者POSIX的aio_read()来说,调用它之后，函数立即返回，操作系统在后台同时开始读操作。 操作系统提供了异步的模式来传输网络数据，即：应用程序把要发送的数据交给操作系统，操作系统把数据放在系统缓冲区后应用程序该干嘛干嘛去。操作系统发送完成后，会给应用系统一个回执，告诉应用程序：刚才那个包发送完成了！
在以上三种IO形式中，非阻塞异步是性能最高、伸缩性最好的。 Proactor模式在单CPU单核系统应用中有着无可比拟的优势。
改进的解决方案
将Reactor稍做调整，模拟成异步的Proactor模型(主要是在事件分离器里完成本该事件处理者做的实际读写工作,我们称这种方法为"模拟异步")。 下面的示例可以看看read操作是如何完成的:
- 事件处理者宣称对读事件感兴趣,并提供了用于存储结果的缓存区、读数据长度等参数;
- 分离器等待(比如通过select());
- 当有事件到来(即可读)，分离器被唤醒, 分离器去执行非阻塞的读操作(前面事件处理者已经给了足够的信息了)。读完后，它去通知事件处理者。
- 事件处理器处理用户自定义缓冲区的数据，注册新的事件（当然同样要给出数据缓冲区地址，需要读取的数据量等信息），最后将控制权返还分离器。
我们看到，通过为分离者添加一些功能，可以让Reactor模式转换为Proactor模式。所有这些被执行的操作,其实是和Reactor模型应用时完全一致的。我们只是把工作打散分配给不同的角色去完成而已。这样并不会有额外的开销，也不会有性能上的的损失，我们可以再仔细看看下面的两个过程，他们实际上完成了一样的事情：
Boost.Asio类库，其就是以Proactor这种设计模式来实现，参见：Proactor（The Boost.Asio library is based on the Proactor pattern. This design note outlines the advantages and disadvantages of this approach.），其设计文档链接：http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/design/index.html
所有同步等待策略可划分为两组:
- edge-triggered (e.g. Linux实时信号) - signal readiness only when socket became ready (changes state);
- level-triggered (e.g.
select(),poll(), /dev/poll) - readiness at any time.
如：ACE技术论文集-第8章 前摄器（Proactor）：用于为异步事件多路分离和分派处理器的对象行为模式
ACE技术论文集-第7章 ACE反应堆（Reactor）的设计和使用：用于事件多路分离的面向对象构架