CODEWITHSUNDEEP
node.jsmultithreading
POOJA GUPTA
POOJA GUPTA

Reputation: 2355

how is blocking I/O handled via the threadpool in Node.js?

I have recently studied Node.js and tried understanding the Node.js architecture in depth. But still after going through multiple articles and links like stack overflow, node.js blogs, I am confused as how both single thread with event loop and the multi-threaded blocking I/O requests that are part of client requests or events can happen at the same time.

According to my study, the single thread with event loop keeps on polling on event queue to know if the client request has come. As soon as, the event or request is found, it checks if it is blocking i/o or non-blocking operation. If it is found to be non-blocking then the response is sent back to the client immediately. But if the request has blocking i/o operation then the request is assigned a thread from threadpool,and the single thread continues with the other requests. Essentially, this means that every blocking I/O operation within the clients requests are assigned a thread and here system is working as multithreaded.

My confusion is that how can that single thread and the threaded blocking I/O operations be performed at the same time. The execution of single thread is concurrent but the blocking i/o(s) are also happening at the same time. How can this be achieved on a single machine which is having both single thread and blocking I/O thread executing in parallel on a single core processor when CPU can execute one thread at a time. Also, are these threads both single event loop thread and threadpool threads user-level threads?

Although, I know that the Blocking I/O threads are handled by the libraries of the external modules but still those modules will be using up threads and executing them in the same space as that of the single level thread. So, how are the two getting executed?

I am new to this framework.

Upvotes: 0

Views: 414

Answers (1)

freakish
freakish

Reputation: 56477

Node.js process consists of the main thread which runs an event loop and worker threads. These worker threads are not explicitly available to the coder.

Now when you do a syscall from your code (i.e. calling a Node.js function which internally does a syscall) then depending on whether these are blocking (e.g. file I/O) or non-blocking (e.g. socket I/O) the job might be send to a worker thread. However a callback is always registered with the event loop. So if the worker finishes processing a job it notifies the event loop and so from coder's point of view the operation was asynchronous.

Now it doesn't really matter whether CPU is multi or single threaded. That's because reading from a disk takes some time and during that time CPU is not busy on that thread. The OS knows that it should switch context during that time. So even if you have single threaded CPU then the event loop takes majority of its time.

And also by threads I understand real kernel-space threads, not user-space threads. Doing that over user-space threads is pointless since you would block the whole kernel-space thread during blocking I/O.

Upvotes: 1

Related Questions