为何Boost的asio要使用proactor模式实现?

最新推荐文章于 2021-05-14 12:47:06 发布

转载最新推荐文章于 2021-05-14 12:47:06 发布 · 149 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/zhangjie830621/blog/353728

文章标签：

#c/c++ #epoll #python

本文探讨了Boost ASIO在网络库中使用Proactor模式的原因，尤其是在Linux环境下与Reactor模式相比的性能差异，并分析了Windows与Linux不同网络编程模型的特点。

2019独角兽企业重金招聘Python工程师标准>>>

Linux下高性能的网络库中大多使用的Reactor 模式去实现,Boost Asio在Linux下用epoll和select去模拟proactor模式,影响了它的效率和实现复杂度,
看陈硕的自己的Linux下Reactor网络库和ASIO的性能对比,大概比asio性能(吞吐量)高1/5.既然Linux下网络库用Reactor性能才高,为什么Boost ASIO Linux下要用模拟的Proactor模式?
或者说为什么ASIO不在win和linux都用Reactor模式?这样的选择是不是可以性能更好?和更加适应市场?服务器端毕竟大量都是Linux.

Windows 下很难实现高效可伸缩的 Reactor。首先，Win32 API 里 WaitForMultipleObjects 只能同时等待 64 个 handle (MAXIMUM_WAIT_OBJECTS)；其次 WinSock 的 select() 实现又很 buggy，特别是在错误处理方面有很多奇葩行为（具体见各种跨平台网络库代码中对此的注释）；最后，Windows Vista 新增的 WSAPoll() 函数与 POSIX 的 poll() 又不尽兼容。

Windows 有自己的一套高效异步IO模型（几乎等同于Proactor），同时支持文件IO和网络IO；但 Linux 只有高效的网络同步IO（epoll 之类的 io multiplexing 是同步的Reactor，且不支持磁盘文件），二者的高效IO编程模型从根本上不兼容（Windows 可以把网络事件发到 GUI 线程的事件队列中，有点类似 Reactor，但是似乎一个进程只能有一个 GUI 线程，因此在多核系统上其伸缩性受限）。

因此，ASIO 要想高效且跨平台，只能用 Proactor 模型了。不可避免地会在 Linux 上损失一点儿效率。

转载于:https://my.oschina.net/zhangjie830621/blog/353728