我正在尝试了解Node.js / libuv中非阻塞网络IO的工作原理。我已经发现文件 IO是使用libuv工作线程完成的（因此，在后台线程中）。但是，在各个地方都声明网络 IO是使用epoll，kqueue等系统调用以非阻塞方式完成的（取决于操作系统）。 / p>
现在我想知道这是否意味着实际IO部分（read()）仍然在主线程上完成，因此阻塞，即使e。 G。使用epoll？至于我的理解，epoll仅通知可用事件，但实际上并不执行读/写操作。至少在我发现的例子中（例如http://davmac.org/davpage/linux/async-io.html）epoll总是与read系统调用结合使用，这是一个阻塞IO操作。
换句话说，如果libuv使用单个线程和epoll，要在数据可供读取时发出通知，那么接下来的读取操作就会在主线程上执行，从而可能在mainthread上阻止其他操作（考虑网络请求）？
答案 0 :(得分：0)
epoll/poll/select始终报告引用文件的文件描述符已准备好进行读/写，但read/write可能会阻止等待读/写数据。这就是文件I / O必须在一个单独的线程中完成的原因。
而带有管道和套接字的非阻塞send/recv实际上是非阻塞的，因此可以在I / O线程中完成，而不会有阻塞线程的风险。