Node js : how libuv thread pool works?

Question

I am learning Node Js, I understand the heart of node js is the reactor pattern which is based on the event loop.

When any event occurs it goes to the event queue and then gets picked up by the stack once it's running tasks get over, this happens if the event is a non- blocking one but if it is a blocking request then event loop passes it to a thread from a thread pool of libuv.

Now my doubts are:

1. Once the execution is over does libuv thread passes the request back to event queue or event loop? , different tutorial has a different scenario.

2. Thread pool in libuv has 3 threads more, now suppose 10 users tries to login and everyone at the same time (some app like facebook or so), how only, and the threads are blocked as they want to connect to DB, so how only three threads will handle so much load?

I am really confused and did not get a good explanation of these doubts anywhere, any help will be appreciated.

Avlona

Libuv uses 4 threads as default however this can be changed using UV_THREADPOOL_SIZE. – Calyces

Answer 1

When any event occurs it goes to the event queue and then gets picked up by the stack

event does not get picked up by the stack. it is passed to call stack by event loop.

if it is a blocking request then event loop passes it to a thread from a thread pool of libuv.

There are ONLY FOUR things that use the thread pool - DNS lookup, fs, crypto and zlib. Everything else execute in the main thread irrespective or blocking or not.

So logging is a network request and threadpool does not handle this. Neither libuv nor node has any code to handle this low level operations that are involved with a network request. Instead libuv delegates the request making to the underlying operating system then it just waits on the operating system to emit a signal that some response has come back to the request. OS keeps track of connections in the network stack. But network i/o is handled by your network hardware and your ISP.

Alternator

Just one remark. Custom C++ modules might use the thread pool as well. – Calyces

@Alternator "it just waits on the operating system to emit a signal that some response has come back to the request" Does it mean it goes idle or event loop blocks? Or does it registers some event that keeps polling for the status of the request to OS? – Gauguin

@8bitIcon The libuv filesystem operations are different from socket operations. Socket operations use the non-blocking operations provided by the operating system. Filesystem operations use blocking functions internally, but invoke these functions in a thread pool and notify watchers registered with the event loop when application interaction is required. – Alternator

@8bitIcon nikhilm.github.io/uvbook/filesystem.html – Alternator

@8bitIcon docs.libuv.org/en/v1.x/design.html – Alternator

Answer 2

Once the execution is over does libuv thread passes the request back to event queue or event loop?

From the node.js point of view does it make a difference?

2) Thread pool in libuv has 3 threads more , now suppose 10 users tries to login and everyone at the same time (some app like facebook or so), how only , and the threads are blocked as they want to connect to DB, so how only three threads will handle so much load ?

libuv uses threat pool but not in a "naive" way. Most asynchronous requests are filesystem/tcp interaction which are handled via select(). You have to worry about the thread pool only when you create a custom C++ module and manually dispatch a CPU/IO blocking task.

Showalter

Some of the crypto functions are not pollable either. – Calyces