理解libuv / epoll /无阻塞网络IO

Question

我试图了解非阻塞网络IO是如何在Node.js/libuv中工作的。我已经发现文件 IO是使用libuv工作线程完成的(因此，在后台线程中)。但是，许多地方都指出，网络 IO是使用epoll、kqueue等系统调用(取决于操作系统)以非阻塞方式完成的。

现在，我想知道这是否意味着实际的IO部分(read())仍然在主线程上执行，从而阻塞，即使使用了epoll？就我的理解而言，epoll只通知可用的事件，而不实际进行读/写。至少在我发现的示例中(例如，http://davmac.org/davpage/linux/async-io.html)，epoll总是与read系统调用结合使用，这是一个阻塞IO操作。

换句话说，如果libuv使用的是单个线程和epoll，那么在可以读取数据时发出通知，那么接下来的读取操作是否在主线程上执行，从而潜在地阻塞了主线程上的其他操作(考虑网络请求)？

Answer 1

引用文件的文件描述符总是报告为epoll/poll/select已准备好进行读/写，但是，read/write可能会阻止等待数据的读写。这就是为什么文件I/O必须在单独的线程中完成的原因。

然而，具有管道和套接字的非阻塞send/recv确实是非阻塞的，因此可以在I/O线程中完成，而不存在阻塞线程的风险。