Now, how your nodejs/python/c# ASYNC AWAIT WORKS???

Under the hood, on the kernel level it is done via epoll. Epoll is specific kernel construct that can watch MULTIPLE blocking calls, e.g. multiple socket FDs and their .read() or .accept().

Before in blocking example, thread got blocked during .read(). It means it will wake up only when wait_queue of socket itself will be triggered by interrupt.

In THIS example, we are blocking the thread only on epoll_wait(). For that we have specific epoll wait_queue, that is interrupted by ANY FDs that were registered to epoll.

Now, how registration works? Whenever you create socket fd -> you are adding this fd to epoll red-black tree and connecting epoll callback with socket wait_queue. You can do that with MULTIPLE SOCKETS, thus waking epoll on earliest update.

It is pretty much JS event loop approach.
Now socket wait_queue gets interrupt and triggers epoll wait_queue and code gets update. Then we read socket buffer

#kernel #network

So before we deep dive into that bug, lets recall again.

Blocking .read -> puts the task to sockets file descriptor wait_queue -> later on interrupt from NIC wakes this task by going to this wait_queue and call .wakeup()/marking task runnable.

Non-blocking .read with epoll - does not block, if the receve_queue (read buffer) in socket descriptor is empty it will return EAGAIN instead of blocking the thread. The blocking part is on epoll_wait -> that parks the task in epoll waiting queue (not socket fd waiting queue). And gets woken up by socket wait_queue task being calling epoll callback that wakes up epoll wait_queue task.

This way, epoll can “react” to any interrupt on any socket fds, not just single one (it has many of them), while blocking .read() will wait for this specific socket wakeup only.