了解 *nix 上异步编程的基础知识

Question

一段时间以来，我一直在谷歌上进行大量搜索，以了解在 nix 机器上实现异步编程/行为的各种方法，并且（正如我之前所知）得到确认，仍然没有真正的异步模式（并发） Linux 上使用单线程），Windows 上也可以使用（IOCP）。

以下是针对 Linux 的几种替代方案：

1. select/poll/epoll :: 无法使用单线程完成，因为 epoll 仍然阻塞调用。此外，受监视的文件描述符必须以非阻塞模式打开。
2. libaio:: 我所知道的是，它的实现很糟糕，而且它仍然基于通知，而不是像 Windows I/O 完成端口那样基于完成。
3. Boost ASIO :: 它在 Linux 下使用 epoll，因此不是真正的异步模式，因为它生成完全从用户代码中抽象出来的线程以实现前摄器设计模式
4. libevent ::如果我更喜欢 ASIO，有什么理由去选择它？

现在问题来了:)

1. 使用 epoll 编写快速可扩展网络服务器的最佳设计模式是什么（当然，必须在这里使用线程:(）
2. 我在某处读到“只有套接字可以在非阻塞模式下打开” " 因此 epoll 仅支持套接字，因此不能用于磁盘 I/O。 上面的说法有多真实？为什么不能使用 epoll 在磁盘 I/O 上进行异步编程？
3. Boost ASIO 在 epoll 调用周围使用了一把大锁。我实际上并不理解它的含义以及如何使用 asio 本身来克服它。 类似问题
4. 如何修改 ASIO 模式以处理磁盘文件？有推荐的设计模式吗？

希望有人能够用很好的解释来回答所有问题。任何解释 epoll 和 AIO 设计模式的实现细节的源链接也值得赞赏。

Answer 1

Boost ASIO :: 它在Linux下使用epoll，因此不是真正的异步
模式，因为它产生完全从用户抽象的线程
实现前摄器设计模式的代码

这是不正确的。 Asio 库在最新的 Linux 内核版本上默认使用 epoll()。但是，调用 io_service::run() 的线程将根据需要调用回调处理程序。 Asio 库中只有一个地方使用线程来模拟异步接口，文档：

每个 io_service 都有一个额外的线程用于模拟异步
主机分辨率。该线程是在第一次调用时创建的
ip::tcp::resolver::async_resolve() 或
ip::udp::resolver::async_resolve()。

这并不会使该库“不是真正的异步模式”，正如您声称的那样，事实上，根据定义，它的名称与您不一致。

1) 使用 epoll 编写快速可扩展网络服务器的最佳设计模式是什么（当然，这里必须使用线程:(
）

我建议使用Boost Asio，它使用proactor设计模式。

3) Boost ASIO 在 epoll 调用周围使用一大锁。我实际上并没有
了解它的含义以及如何克服它
asio本身

epoll 反应器使用互斥体来调度处理程序，尽管实际上这对于大多数应用程序来说并不是一个大问题。有一些特定于应用程序的方法可以缓解这种行为，例如每个 CPU 的 io_service 来利用数据局部性。请参阅我对有关此主题的类似问题的回答。 Asio 邮件列表也经常对此进行讨论。

4) 如何修改 ASIO 模式以处理磁盘文件？有没有
推荐的设计模式？

正如您所指出的，Asio 库本身并不支持文件 I/O。已经多次尝试将其添加到库中，我建议在

Answer 2

首先：

得到确认，Linux 仍然没有真正的异步模式（使用单线程的并发），可用于 Windows (IOCP)。

您可能有一个小误解，异步可以构建在“轮询”api 之上。

更重要的是，“reactor”（类似 epoll）API 比“proactor”API (IOCP) 更强大，因为
第二个可以根据第一个来实现（但反之则不然）。

还有一些“真正”异步的操作，例如磁盘 I/O，一些其他工具可以与信号组合，并且 Linux 特定的 signalfd 可以提供其他一些情况的完整覆盖。

底线。 epoll 是真正的异步 I/O