Understanding libuv / epoll / non-blocking network IO

Question

I am trying to understand how non-blocking network IO is working in Node.js / libuv . I already found out that file IO is done using libuv worker threads (thus, in a background thread). However it is stated in various places that network IO is done in a non-blocking fashion using system calls like epoll , kqueue , etc (depending on operating system).

Now I am wondering if this means that the actual IO part ( read() ) is still done on the mainthread, and thus blocking, even if eg epoll is used? As for my understanding, epoll only notifies about available events, but does not actually do the read/write. At least in the examples I found (eg http://davmac.org/davpage/linux/async-io.html ) epoll is always used in combination with the read system call, which is a blocking IO operation.

In other words, if libuv is using a single thread and epoll , to have a notification when data is available to read, is the then following read operation beeing executed on the mainthread and thus potentially blocking other operations (thinking of network requests) on the mainthread?

Answer 1

File descriptors referring to files are always reported as ready for read/write by epoll/poll/select , however, read/write may block waiting for data to be read/written. This is why file I/O must be done in a separate thread.

Whereas non-blocking send/recv with pipes and sockets are truly non-blocking and hence can be done in the I/O thread without risk of blocking the thread.