我正在尝试理解在Node.js/libuv中非阻塞网络IO是如何工作的。我已经发现文件IO是使用libuv工作线程完成的(因此在后台线程中)。然而,各种地方都指出,网络IO是使用诸如epoll、kqueue等系统调用以非阻塞方式完成的(取决于操作系统)。
现在我想知道这是否意味着实际的IO部分(read())仍然在主线程上进行,因此是阻塞的,即使使用了epoll等。就我所知,epoll只是通知可用事件,但并不实际执行读/写。至少在我找到的示例中(例如http://davmac.org/davpage/linux/async-io.html),epoll总是与阻塞IO操作的read系统调用结合使用。
换句话说,如果
现在我想知道这是否意味着实际的IO部分(read())仍然在主线程上进行,因此是阻塞的,即使使用了epoll等。就我所知,epoll只是通知可用事件,但并不实际执行读/写。至少在我找到的示例中(例如http://davmac.org/davpage/linux/async-io.html),epoll总是与阻塞IO操作的read系统调用结合使用。
换句话说,如果
libuv
正在使用单个线程和epoll
,那么当数据可读时,接下来的读取操作是否在主线程上执行,从而可能阻塞主线程上的其他操作(考虑网络请求)?
read
系统调用不会被阻塞。因此,实际的IO操作仍然在后台进行吗? - user826955