Epoll/Multiplexing是否适合于发出网络请求而不是“监听”传入的请求？

Question

我正在研究异步IO、IO的并发模型以及windows、linux和大多数使用的web框架上的工作方式。

我很难理解为什么像node.js或ngnix那样的单线程事件循环在处理想要进行IO操作的请求时(比如从另一个服务获取数据的HTTP请求)使用一个专用线程来处理每个IO操作，而不是使用一个线程和Epoll来处理所有这些操作。

让我更好地解释：

• 每次我读到关于Epoll的文章时，我都会从服务器的角度阅读示例或教程:我是一个服务器->，我讨厌线程的上下文切换-> Epoll，让我只使用一个线程处理大量传入的请求。好的。
• 因此，我构建了一个像node.js这样的服务器技术:单线程事件循环和非阻塞IO操作。如何进行非阻塞的IO操作？我在专用IO线程上执行它们，每个线程都会阻塞，直到IO操作完成(允许主事件线程自由处理其他请求)。
• 这意味着，如果我接收到100个请求，并且每个请求都必须执行IO操作，我最终可能会使用100个线程或线程池中可用的最大线程数，留下大量IO操作等待一个空闲线程。

那么，使用Epoll或其他多路复用库来保存用于管理传入请求的线程计数又有什么意义呢?如果我最终能够为管理每个已处理的请求所需的IO操作执行大量上下文切换？为什么不使用Epoll在单个(或少数)线程上“批处理”这些IO操作？

Answer 1

Select和Epoll过去和现在都是有缺陷的API。它们有效地告诉我们，如果在特定的文件描述符上可以执行I/O操作，但实际上不允许我们以异步的方式执行I/O操作:一旦执行读或写，就会被阻塞，直到该操作完成为止。

因此，常见的解决方法是将潜在阻塞的I/O操作委托给线程池(每个操作不是一个线程)。这是相当有效的，因为这些线程将大部分时间用于I/O操作(无论是在syscalls上还是在等待主线程的新I/O任务上)。向I/O线程池发送任务不需要上下文切换。打开的连接数可以远远高于当前正在执行的I/O操作数。

有更好的方法可用，特别是Windows开创的完成端口。在5.1版(2019年5月)的io_uring中，Linux终于获得了完全异步的I/O。