了解libuv / epoll /非阻塞網絡IO

Question

我試圖了解Node.js / libuv非阻塞網絡IO的工作libuv 。 我已經發現文件 IO是使用libuv工作線程完成的（因此，在后台線程中完成）。 但是，在各個地方都說過， 網絡 IO是通過使用epoll ， kqueue等系統調用（取決於操作系統）以非阻塞方式完成的。

現在，我想知道這是否意味着即使在使用了epoll情況下，實際的IO部分（ read() ） 仍在主線程上完成並因此阻塞了？ 據我了解， epoll僅通知可用事件，而實際上不進行讀/寫。 至少在我發現的例子（例如http://davmac.org/davpage/linux/async-io.html ） epoll始終與組合使用read系統調用，這是阻塞IO操作。

換句話說，如果libuv使用單個線程和epoll來在有數據可供讀取時發出通知，則在主線程上執行隨后的讀取操作beeing，從而潛在地阻止了該線程上的其他操作（網絡請求的思考）主線程？

Answer 1

始終通過epoll/poll/select將指向文件的文件描述符報告為已准備好進行讀/寫，但是， read/write可能會阻止等待數據被讀/寫。 這就是為什么文件I / O必須在單獨的線程中完成的原因。

帶有管道和套接字的非阻塞send/recv實際上是非阻塞的，因此可以在I / O線程中完成而不會阻塞線程。