我试图了解非阻塞网络 IO 是如何工作的Node.js/libuv。我已经发现了fileIO 是使用完成的libuv工作线程（因此，在后台线程中）。不过很多地方都说networkIO 是使用系统调用以非阻塞方式完成的，例如epoll, kqueue等（取决于操作系统）。
现在我想知道这是否意味着实际的 IO 部分（read()) is still在主线程上完成，因此会阻塞，即使 e. G。epoll用来？就我的理解而言，epoll仅通知可用事件，但实际上并不执行读/写操作。至少在我发现的例子中（例如http://davmac.org/davpage/linux/async-io.html http://davmac.org/davpage/linux/async-io.html) epoll总是与read系统调用，这是一个阻塞IO操作。
换句话说，如果libuv使用单线程并且epoll，要在数据可供读取时收到通知，接下来的读取操作是否正在主线程上执行，从而可能阻塞主线程上的其他操作（考虑网络请求）？
引用文件的文件描述符始终报告为可供读/写epoll/poll/select， 然而，read/write可能会阻塞等待数据读/写。这就是为什么文件 I/O 必须在单独的线程中完成的原因。
而非阻塞send/recv使用管道和套接字确实是非阻塞的，因此可以在 I/O 线程中完成，而不会有阻塞线程的风险。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
