对网络库协程的思考——读brpc有感

bthread的作用之一：将Reactor中的同步IO改异步IO。

理论上Reactor效率不如Proactor，具体表现在虽然Reactor模型避免了等待可读/可写事件就绪的时间，但是read/write调用本身的时间是不可避免的（即内核缓冲区和用户缓冲区之间的数据拷贝是占用当前线程CPU时间的），而Proactor却可以避免这个时间，所以效率更高。

那么为什么说Proactor效率更高呢？虽然Proactor不需要等待read/write本身，但只是把读写处理时间转交给了操作系统内核线程，总的处理时间并不会减少。

关键在于通过把read/write的时间转交给操作系统，当前线程可以继续去处理下一个连接，虽然总的吞吐量没有变化，但是每条请求的平均处理时延降低了。所以brpc中把IO操作交给新的bthread执行（https://github.com/apache/incubator-brpc/blob/master/docs/cn/io.md#%E6%94%B6%E6%B6%88%E6%81%AF）就相当于交给支持异步IO的操作系统去执行，它们都可以降低请求平均时延。

hook系统调用

有了异步IO和bthread的启示，我们会想到将所有会发生阻塞的系统调用都以这种方式改写，这就引出了hook。

简单来说hook库代码是对系统调用的包装，目的是当系统调用要阻塞时，不是直接阻塞当前线程，而是阻塞当前bthread，当前线程立即去执行另一个bthread，从而避免了线程阻塞。

这相当于把系统调用 + 线程的模型下放为hook后的系统调用 + 协程。（系统调用阻塞时发生线程切换，hook后的系统调用阻塞时发生协程切换，而协程切换开销小于线程，所以后者性能更好）。

但是brpc并没有hook系统调用，这是因为：

• bthread阻塞可能切换系统线程，依赖系统TLS的函数的行为未定义。
• 和阻塞pthread的函数混用时可能死锁。
• 这类hook函数本身的效率一般更差，因为往往还需要额外的系统调用，如epoll。