Kitura的IO

背景知识

关于同步／异步，阻塞／非阻塞的解释除了参见《Unix网络编程》之外，知乎中，“愚蠢”和“大姚”分别进行了通俗和详尽的解释。

参考：https://www.zhihu.com/question/19732473

阻塞式的结构性能一定是低下的，这里主要比较同步非阻塞式和异步非阻塞式结构，也就是Reactor和Proactor这两个结构。

参考：http://www.artima.com/articles/io_design_patterns.html

---

正文

Reactor：多路分用器等待事件告知读写准备就绪，将事件分发给合适的Handler，Handler真正负责读写工作（这里就是同步的地方）。

Proactor：IO的读写操作是由OS完成的。Handler将用户定义好的缓冲区作为参数传给OS，等待OS完成读写操作后，由事件的多路分用器通知Handler。

Reactor中的Handler关注（Ready to Read）事件，Handler负责读写。

Proactor中的Handler关注（Receiving Completion）事件，OS负责读写。

为什么不能向上层程序员提供统一的接口，让程序员不关心其内部实现到底是Reactor还是Proactor呢？

由于Proactor结构需要OS Async API的支持，但并不是所有的OS都提供健壮的API。所以很难设计出统一的外部接口，所以也就很难设计出可移植的框架来封装与操作系统有关的操作。不过文中也提到了一种简单的方法来解决这个问题，具体见Page 2/3.

理论上Proactor模式具有最好的扩展性和性能，但Nginx选择了Reactor，其原因如下：

Proactor逻辑实现复杂，并且Proactor需要操作系统的异步API支持，而Linux主要还是通过Epoll和Select来进行事件驱动。对异步API支持比较好的是Windows IOCP。

Kitura在OSX下使用了dispatch_io，在Linux下使用了Epoll。其原因是Epoll在Linux下性能较低，原因不明。

参考：https://github.com/IBM-Swift/Kitura/issues/121

---

Reference

https://segmentfault.com/a/1190000002715832