I got this after some research, hope it helps. The statement "blocking threads are non-blocking" is not entirely accurate. It's important to make a distinction between the nature of the operation and the execution model: Nature of the operation: A blocking operation is one that suspends the execution of the current thread until it completes. This means that while the thread is waiting, it cannot execute any other code. Execution model: Node.js utilizes a single-threaded event loop with a pool of worker threads. The event loop is responsible for handling non-blocking I/O and scheduling tasks. Worker threads are used to execute blocking operations asynchronously. Therefore, while an individual operation might be blocking, the execution model in Node.js utilizes worker threads and the event loop to manage these blocking operations in a non-blocking manner. This allows the main thread to remain responsive and handle other tasks while the blocking operations are running in the background. Here's a more accurate way to express the concept: Node.js can handle blocking operations in a non-blocking way by utilizing worker threads and the event loop. This statement clarifies that the blocking nature of individual operations doesn't prevent Node.js from being a non-blocking environment overall. ------------------------------------------------------------------------------------ Yes, that's correct. Node.js internally decides whether a task will run on the main thread or a worker thread based on several factors, including: * **Nature of the operation:** Long-running and blocking operations are more likely to be assigned to worker threads, while short-lived and non-blocking tasks are typically handled by the main thread. * **Available resources:** Node.js considers the available CPU cores and memory when deciding whether to utilize worker threads. If resources are limited, it might prefer to run even blocking tasks on the main thread to avoid overhead. * **Application configuration:** Some libraries and frameworks might specify how certain tasks should be handled, influencing whether they run on the main thread or a worker thread. * **Node.js version and configuration:** Different versions of Node.js and specific configurations might have different heuristics for deciding when to use worker threads. Even for blocking operations like `fs.readFileSync`, Node.js might choose to execute them on the main thread if: * The operation is very fast and doesn't significantly block the main thread. * Utilizing a worker thread would introduce more overhead than simply waiting for the operation to finish on the main thread. * The application is running on a system with limited resources, and using a worker thread would be detrimental to performance. Ultimately, Node.js aims to optimize performance and resource utilization by intelligently allocating tasks between the main thread and worker threads. While developers can influence this behavior through libraries, frameworks, and application architecture, the final decision ultimately rests with the Node.js runtime based on its internal analysis.
synchronous (blocking) tasks are handled by the main thread (event loop), while asynchronous (non-blocking) tasks are offloaded to the thread pool (via libuv) or system APIs, allowing the main thread to continue processing other tasks. When async tasks (like I/O or database queries) complete, their callbacks are queued in the event loop for execution. This ensures non-blocking behavior for async operations, while blocking tasks can halt the event loop if not managed properly.
Blocking Requests: 1. When your code encounters a blocking request (like synchronously reading a large file), it goes directly onto the call stack. 2. The event loop prioritizes the call stack, and the blocking request is executed immediately. 3. The entire main thread of Node.js gets tied up waiting for the blocking operation to finish. 4. The event queue and any asynchronous tasks have to wait until the blocking request completes. Asynchronous Tasks and Callbacks: 1. When your code initiates an asynchronous operation (like reading a file asynchronously), the callback function representing that task is added directly to the event queue. 2. The callback function doesn't go on the call stack immediately because the asynchronous operation takes time to complete (e.g., waiting for the file to be read). 3. The event loop continues processing tasks on the call stack, focusing on synchronous tasks. 4. Only once the call stack is empty does the event loop check the event queue for waiting callbacks. 5. The event loop picks up the oldest callback from the queue (FIFO) and pushes it onto the call stack. 6. Now, the callback function gets its turn for execution on the call stack. I hope this would help...
One correction: 8 CPU cores don't necessarily mean we can only assign 8 threads. We can assign many more threads, but if the number of threads exceeds the number of cores, the CPU will context switch between them, leading to performance degradation. This happens because each thread consumes system memory in the form of a Thread Control Block (TCB). If frequent Context Switches occur, the CPU core has to frequently read and write the TCB from main memory to the CPU registers, which can degrade the performance.
Great sir... Really helped me to understand this whole working. Am a fresher and wanted to learn node.js.. literally feels like my elder brother is teaching.. thankyou so much sir
The synchronous tasks run on a single thread, because JS is a single-threaded language. The thread pool is used only for blocking operations that are CPU-intensive.
I think, there is mistake. File reading is itself a Async operation. If this async task run on main thread (e.g. readFileSync), it will block other operation. That is why this is blocking operation. If this async task run on another thread using threadPool, it will not block other operation. That is why this is non- blocking operation.
I think you missed to mention one important concept about event demultiplexer. Event demultiplexer watches the I/O resources and once they are done with I/O task then it pushes set of events to the Event Queue and then the callbacks are executed and control comes back to the event queue. It goes in a cycle or loop which we called an event loop.
hi, i am confused now, i think non-blocking operations are handled by worker threads and blocking operations are handled by main thread. please clear it out.
brother i think your statement is wrong.Asynchronous task is handled by thread pool while synchronous or blocking task is handled by the main thread.if i am wrong please i am open to your explanation
thanks dude for the video. Just a sort of suggestion, I think you should not fear on explaining complex topics, thinking viewers if not get it might dislike that. I am confused now , node is single threaded. So how come a thread pool with so many threads. Secondly if it goes for a worker thread than it should be non blocking no? as each of the task has its own independent thread? @Piyush can you help here man. Or anyone?
in blocking opertion node use's C library which is libuv library using this it achives mutli threading and in node cluster module can achive same feature
bro nodejs is synchronous architecture but it is asynchronous by default just sort it out in a way blocking request executes line by line but when it comes to non blocking operation it executes the operation like which was simple adn easy adn further move to the execution or loops part
Bhaiya aap bahut sache padhate ho.Aapki voice bahut aachi hai ek dum polite.Aap dikhte bhi bahut smart ho.Thank you bhaiya for this amazing playlist ❤❤❤
I'm having the same doubt but lets discuss our points here. So, as per my research, I think in both the cases requests are exceuted by the thread pool only, in the blocking requests (Sync) - only 1 thread is used to execute the operation and when it is done, then only 2nd request comes in. so it's like we're not using node.js to its fullest (working as a single threaded system), in the non blocking requests (Async) - all the requests gets parallelly exceuted, but still it will be limited to its max thread pool size (for example - 4 or 8 in Piyush's laptop) but here we have the advantage of nodeJS can work on the next task rather than gets stuck like in the case of blocking requests. (working as a multi-threaded system).
Node.js uses an event-driven, non-blocking I/O model which makes it well suited for handling concurrent connections and handling a high number of requests. When a request is received, the server creates an event and adds it to an event queue. The event loop then runs and processes the events in the queue one by one. This allows Node.js to handle many requests simultaneously without blocking the execution of other requests. Node.js also uses a callback function, which is executed once the request has been processed, to return the response to the client. The event loop is responsible for executing non-blocking requests in Node.js. The event loop is a mechanism that allows Node.js to perform non-blocking I/O operations. It works by continuously running and checking the event queue for new events to process. When a new request is received, it is added to the event queue in the form of an event. The event loop then picks up the event and starts executing it. Once the event has been processed, the callback function associated with the event is called, which sends the response back to the client. This entire process happens in a non-blocking manner, allowing Node.js to handle multiple requests simultaneously without blocking the execution of other requests.
YOU DID MISTAKE "No, blocking operations do not go to the thread pool. Instead, they execute directly on the main thread, which is why they are considered "blocking."
Nope you are wrong Non-blocking requests are handled by the Event Loop, which processes tasks asynchronously. This is the ideal behavior for Node.js, as it allows the main thread to handle multiple requests at the same time without being blocked. Blocking requests, such as those involving file system operations (e.g., reading large files) or CPU-intensive computations, can block the Event Loop. However, to prevent the main thread from becoming unresponsive, Node.js offloads these blocking operations to worker threads or uses the libuv thread pool. The thread pool handles these operations in parallel, so the Event Loop can continue processing other events while waiting for the blocking task to finish.
It's wonderful to see many people pointing out the mistake of Piyush sir, while they know other people have said it already..still writing. I wonder why the Indians perform poor in open-source when such great minds exist !! The comment section is full with the correction of that mistake !!
Great explanation bro but can you please make a video on how to fetch data quickly from mongo db with huge number of collection with aggregation and indexing
Piyush - we should write asyn function if it is related to read/write file or network operation .. otherwise other program execution will be blocked for unecessary time ..
Now you question is: But if I am using await I need to wait until the response not coming So the answer is: Yes, that is correct. When using await, the code will wait for the asynchronous operation to complete before moving on to the next line of code. This means that if the response is not yet available, the code will wait until it is before continuing. However, this does not block the event loop, so other operations can still be processed while waiting for the response.
conclusion - it's always a good practice to write non blocking (asynchronous) code, meaning in which the there is no blocking of threads. we can only have workers equal the number of cores in our CPU in the thread pool.
Key takeaways from this video:- ## how nodejs works? nodejs architecture:- -> the architecture of nodejs or it's flow starts with a client (a user of our server). -> so what does this client do? this client makes a request to our server, so this request comes to our server. -> whatever request comes to us, it is first of all within this *event queue*. for example, if the user-1 has made a request, that will first go in the event queue. after that if user-2 requests something then that will also go in the event queue. -> so whatever requests come they all will go inside the event queue, all these request goes to the event loop. -> event loop? it's a loop which is always watching our event. it picks the requests based on FIFO (first in first out) principle. -> so what does this event loop do? it's work is to watch over the event queue, and remove these requests one by one from the queue. -> when a request is picked up from this queue, that request can be of two types: blocking operations (sync), and non-blocking operations (async). so what does this event loop do? it first checks whether this particular request is blocking or non-blocking operation. -> if it's a non-blocking operation, event loop will pick it up, process it and sent the response to the user. -> if it's a blocking operation, then to solve this particular request, this blocking operation goes to the thread pool (a pool which has all the threads), these threads are responsible to fulfill your blocking operation. i.e., a thread is assigned to every request. -> this blocking operation requests the thread pool that i need a thread or a worker. so this thread pool will check is there any thread or worker available, as it has limited threads. -> if a thread or a worker is available, then it will put it to work and when the work gets completed, then that worker will comeback in the thread pool and return the result, that result will be returned to us and we will send the response to the user.
For Non-Blocking or Async code , how it will work behind the scenese like how it will let other code to execute first and then it will execute at the end ??
Hello Piyush ji I want to ask one question that if node server is running with web socket server then at that time should there is any role of request of http blocking or non blocking?
I was watching this series and on reaching this Video, i thought why i haven't subscribed n just subscribed the channel..and boom just saw the comment section 🤡😐😵💫💀 Dear Piyush its better to update this video Regards A happy Learner from your channel.
Bro ,you are teaching wrong synchronous task of nodejs is only run in main thread , they dont utilize thread pool , thread pool is availble in libuv to do.........In Node.js, the thread pool is primarily available for handling certain types of asynchronous tasks, such as file system operations, network I/O, and cryptographic operations. It's important to note that the thread pool is not used for executing synchronous tasks; those tasks are executed on the main thread.
Yes, Synchronous tasks are executed in main thread, and async tasks, event loop handles the async tasks, and then adds the callback fn in callback queue
blocking will make use of threads to complete it task, synchronous are blocking code will stop the code there and do not allow execution to next line, then what is the point in having multiple threads when each blocking code do not allow other code to execute ("correct me if any wrong in my understanding")
Hey Piyush, I have a question if nodeJS is single-threaded then how thread pool have 4 threads by default and we can increase it by increasing the number of CPU cores. Can you please help me here, I am quite confused.
Yeah That's true, It all depends on the capabilities of system OS / Core . If it is good the no of worker threads may increase or vice-versa. Also no of worker threads depends upon version of node js so there no thing as default. Also u can increase the no of workers manually although value depends of Capacity of core we are using
Hi piyush, can you please make a seperate dedicated video over this is quite confusing for me at a angle to me. like do we need to use async syntaxes for those blocking code so that the node will assign to another thread or once it understand itself that the code is a blocking code then it's decide to assign a new threads for that perticular task. does a single thread has it's own callstack. all this is confusing for me because I thought all tasks execute in call stack but you overview is quite differnt than the normal event loop concept the concept which says that engine execute line by line once it read the any async syntax it put it aside and start executing the it's sync tasks after all the sync tasks end the event loop then check for the task queue or the microtask queue then if there is any then then event loop will send it to the callstack to execute. but then where is the role of thread in this thoery? or if there is already a video could please share me a link?
Sorry, but i learnt that in Node.js, the blocking (synchronous) operations are handled by the main thread, while the non-blocking (asynchronous) operations are offloaded to the thread pool.
Updated and More Detailed Video: th-cam.com/video/_eJ6KAb56Gw/w-d-xo.htmlsi=ddtvGQ0KGNxttB2u
please provide the link of the slides
I got this after some research, hope it helps.
The statement "blocking threads are non-blocking" is not entirely accurate. It's important to make a distinction between the nature of the operation and the execution model:
Nature of the operation: A blocking operation is one that suspends the execution of the current thread until it completes. This means that while the thread is waiting, it cannot execute any other code.
Execution model: Node.js utilizes a single-threaded event loop with a pool of worker threads. The event loop is responsible for handling non-blocking I/O and scheduling tasks. Worker threads are used to execute blocking operations asynchronously.
Therefore, while an individual operation might be blocking, the execution model in Node.js utilizes worker threads and the event loop to manage these blocking operations in a non-blocking manner. This allows the main thread to remain responsive and handle other tasks while the blocking operations are running in the background.
Here's a more accurate way to express the concept:
Node.js can handle blocking operations in a non-blocking way by utilizing worker threads and the event loop.
This statement clarifies that the blocking nature of individual operations doesn't prevent Node.js from being a non-blocking environment overall.
------------------------------------------------------------------------------------
Yes, that's correct. Node.js internally decides whether a task will run on the main thread or a worker thread based on several factors, including:
* **Nature of the operation:** Long-running and blocking operations are more likely to be assigned to worker threads, while short-lived and non-blocking tasks are typically handled by the main thread.
* **Available resources:** Node.js considers the available CPU cores and memory when deciding whether to utilize worker threads. If resources are limited, it might prefer to run even blocking tasks on the main thread to avoid overhead.
* **Application configuration:** Some libraries and frameworks might specify how certain tasks should be handled, influencing whether they run on the main thread or a worker thread.
* **Node.js version and configuration:** Different versions of Node.js and specific configurations might have different heuristics for deciding when to use worker threads.
Even for blocking operations like `fs.readFileSync`, Node.js might choose to execute them on the main thread if:
* The operation is very fast and doesn't significantly block the main thread.
* Utilizing a worker thread would introduce more overhead than simply waiting for the operation to finish on the main thread.
* The application is running on a system with limited resources, and using a worker thread would be detrimental to performance.
Ultimately, Node.js aims to optimize performance and resource utilization by intelligently allocating tasks between the main thread and worker threads. While developers can influence this behavior through libraries, frameworks, and application architecture, the final decision ultimately rests with the Node.js runtime based on its internal analysis.
such deep info in simple terms; thank you
@AkshaySharma-bg3oj great info, where did you found this? can you share any resources
You explained very well and i hope it would also help others
great , thanks for sharing
Thanks for explaining things in very simple terms.
synchronous (blocking) tasks are handled by the main thread (event loop), while asynchronous (non-blocking) tasks are offloaded to the thread pool (via libuv) or system APIs, allowing the main thread to continue processing other tasks. When async tasks (like I/O or database queries) complete, their callbacks are queued in the event loop for execution. This ensures non-blocking behavior for async operations, while blocking tasks can halt the event loop if not managed properly.
thanks man i was confused btwn blocking and non-blocking
@TejasMore-y5r anytime brother ✌️
Blocking Requests:
1. When your code encounters a blocking request (like synchronously reading a large file), it goes directly onto the call stack.
2. The event loop prioritizes the call stack, and the blocking request is executed immediately.
3. The entire main thread of Node.js gets tied up waiting for the blocking operation to finish.
4. The event queue and any asynchronous tasks have to wait until the blocking request completes.
Asynchronous Tasks and Callbacks:
1. When your code initiates an asynchronous operation (like reading a file asynchronously), the callback function representing that task is added directly to the event queue.
2. The callback function doesn't go on the call stack immediately because the asynchronous operation takes time to complete (e.g., waiting for the file to be read).
3. The event loop continues processing tasks on the call stack, focusing on synchronous tasks.
4. Only once the call stack is empty does the event loop check the event queue for waiting callbacks.
5. The event loop picks up the oldest callback from the queue (FIFO) and pushes it onto the call stack.
6. Now, the callback function gets its turn for execution on the call stack.
I hope this would help...
Thanks
One correction: 8 CPU cores don't necessarily mean we can only assign 8 threads. We can assign many more threads, but if the number of threads exceeds the number of cores, the CPU will context switch between them, leading to performance degradation. This happens because each thread consumes system memory in the form of a Thread Control Block (TCB). If frequent Context Switches occur, the CPU core has to frequently read and write the TCB from main memory to the CPU registers, which can degrade the performance.
Great sir... Really helped me to understand this whole working. Am a fresher and wanted to learn node.js.. literally feels like my elder brother is teaching.. thankyou so much sir
Wow sir
I wish I would have got this playlist earlier
Great Explaination
👏👏👏
The synchronous tasks run on a single thread, because JS is a single-threaded language. The thread pool is used only for blocking operations that are CPU-intensive.
I think, there is mistake. File reading is itself a Async operation.
If this async task run on main thread (e.g. readFileSync), it will block other operation. That is why this is blocking operation.
If this async task run on another thread using threadPool, it will not block other operation. That is why this is non- blocking operation.
Bro, amazing video with full clarity and increases curiosity to watch ur next videos, great work mate
Thanks for the series learned a lot ❤❤
I think you missed to mention one important concept about event demultiplexer. Event demultiplexer watches the I/O resources and once they are done with I/O task then it pushes set of events to the Event Queue and then the callbacks are executed and control comes back to the event queue. It goes in a cycle or loop which we called an event loop.
You and Telusko sir made it very easy to understand the architecture(how node js works) of node js in a very simplified way. Thank u piyush bhai
After all the confusing tutorials, I found the perfect tutorial to learn Node js
You are the one who explain the things in a way to make one comprehend easily.
Great Sir understood each line now i can also teach these topics to anyone😍
Got a very good clarity. THANKS PIYUSH. Liked and Subscribed. Can we have more of these videos please, that should help in coding interviews!
hi, i am confused now, i think non-blocking operations are handled by worker threads and blocking operations are handled by main thread. please clear it out.
akheer kar diya....
bhout great
Ma Sha Allah
Understood everything very grateful for this amazing content.
You explained it very well. Thank you!
great Lecture sir😍
this series is helpful ❤
Just need to confirm
Non blocking is asynchronous
And blocking is synchronous
Non blocking is asynchronous!
And blocking is synchronous !
brother i think your statement is wrong.Asynchronous task is handled by thread pool while synchronous or blocking task is handled by the main thread.if i am wrong please i am open to your explanation
Thank you Piyush bhai your lectures help a lot
Very well explained!
Thanks!
thanks dude for the video. Just a sort of suggestion, I think you should not fear on explaining complex topics, thinking viewers if not get it might dislike that.
I am confused now , node is single threaded. So how come a thread pool with so many threads.
Secondly if it goes for a worker thread than it should be non blocking no? as each of the task has its own independent thread?
@Piyush can you help here man.
Or anyone?
in blocking opertion node use's C library which is libuv library using this it achives mutli threading and in node cluster module can achive same feature
bro nodejs is synchronous architecture but it is asynchronous by default just sort it out in a way blocking request executes line by line but when it comes to non blocking operation it executes the operation like which was simple adn easy adn further move to the execution or loops part
Bhaiya aap bahut sache padhate ho.Aapki voice bahut aachi hai ek dum polite.Aap dikhte bhi bahut smart ho.Thank you bhaiya for this amazing playlist ❤❤❤
😂
hahhaahahaha
One question.. blocking request run by thread, then who is running non blocking request .. please answer sir
I'm having the same doubt but lets discuss our points here. So, as per my research, I think in both the cases requests are exceuted by the thread pool only,
in the blocking requests (Sync) - only 1 thread is used to execute the operation and when it is done, then only 2nd request comes in. so it's like we're not using node.js to its fullest (working as a single threaded system),
in the non blocking requests (Async) - all the requests gets parallelly exceuted, but still it will be limited to its max thread pool size (for example - 4 or 8 in Piyush's laptop) but here we have the advantage of nodeJS can work on the next task rather than gets stuck like in the case of blocking requests. (working as a multi-threaded system).
Node.js uses an event-driven, non-blocking I/O model which makes it well suited for handling concurrent connections and handling a high number of requests. When a request is received, the server creates an event and adds it to an event queue. The event loop then runs and processes the events in the queue one by one. This allows Node.js to handle many requests simultaneously without blocking the execution of other requests. Node.js also uses a callback function, which is executed once the request has been processed, to return the response to the client.
The event loop is responsible for executing non-blocking requests in Node.js. The event loop is a mechanism that allows Node.js to perform non-blocking I/O operations. It works by continuously running and checking the event queue for new events to process. When a new request is received, it is added to the event queue in the form of an event. The event loop then picks up the event and starts executing it. Once the event has been processed, the callback function associated with the event is called, which sends the response back to the client. This entire process happens in a non-blocking manner, allowing Node.js to handle multiple requests simultaneously without blocking the execution of other requests.
@@piyushgargdev Thank you Piyush for clarifying our doubt :)
@@piyushgargdevbookish definition, good answer from @tarush
Its done by thread pool
Thanks bhaiya, u really made it easy.
well explained, thanks!
Nicely explained sir
YOU DID MISTAKE "No, blocking operations do not go to the thread pool. Instead, they execute directly on the main thread, which is why they are considered "blocking."
Nope you are wrong
Non-blocking requests are handled by the Event Loop, which processes tasks asynchronously. This is the ideal behavior for Node.js, as it allows the main thread to handle multiple requests at the same time without being blocked.
Blocking requests, such as those involving file system operations (e.g., reading large files) or CPU-intensive computations, can block the Event Loop. However, to prevent the main thread from becoming unresponsive, Node.js offloads these blocking operations to worker threads or uses the libuv thread pool. The thread pool handles these operations in parallel, so the Event Loop can continue processing other events while waiting for the blocking task to finish.
Awesome lots of doubt clear !
Great... Nice explanation
Good explanation. Liked it.
I first like the lecture then poceed with watching it :)
Great explanation. Thank you
I think blocking (synchronous) code is executed by single main thread while non- blocking (async) code is delegated to thread from thread pool.
Superb 🎉🎉
Amazing explanation Thank you so much
Excellent video, this video will reach lakhs of views in future
Amazing tutorials 🎉...
very good and easy way explain , i like it thanku
Very good explanation ❤
if my cpu has 8 cores then it has 16 threads right? so why cant i use those 16 threads?
It's wonderful to see many people pointing out the mistake of Piyush sir, while they know other people have said it already..still writing. I wonder why the Indians perform poor in open-source when such great minds exist !! The comment section is full with the correction of that mistake !!
Good explanations I love it
Thanks bhaiya
Beautiful explanation
Easy understood
Please react ki playlist bhi lekar aao..
bhai tu mst pdata hia bro ❤❤❤❤❤❤❤❤❤❤
Great explanation bro but can you please make a video on how to fetch data quickly from mongo db with huge number of collection with aggregation and indexing
Good explaination.
Very good explanation
Piyush - we should write asyn function if it is related to read/write file or network operation .. otherwise other program execution will be blocked for unecessary time ..
Very Useful
very easy explaination ever great
is 'await' a blocking or non-blocking operation? What about 'then'?
Now you question is: But if I am using await I need to wait until the response not coming
So the answer is: Yes, that is correct. When using await, the code will wait for the asynchronous operation to complete before moving on to the next line of code. This means that if the response is not yet available, the code will wait until it is before continuing. However, this does not block the event loop, so other operations can still be processed while waiting for the response.
thank u sir ji
One question,in file system lect you told we should use readSync i.e blocking function but here you told to use non blocking operation.pls ans
conclusion - it's always a good practice to write non blocking (asynchronous) code, meaning in which the there is no blocking of threads. we can only have workers equal the number of cores in our CPU in the thread pool.
Awesome ❤
it means non-blocking operations are recommended to use
??
Yes!
can you please also make also videos on Mocha -Chai Framework .. you are brilliant ..:)
Perfect 👌
Key takeaways from this video:-
## how nodejs works? nodejs architecture:-
-> the architecture of nodejs or it's flow starts with a client (a user of our server).
-> so what does this client do? this client makes a request to our server, so this request comes to our server.
-> whatever request comes to us, it is first of all within this *event queue*. for example, if the user-1 has made a request, that will first go in the event queue. after that if user-2 requests something then that will also go in the event queue.
-> so whatever requests come they all will go inside the event queue, all these request goes to the event loop.
-> event loop? it's a loop which is always watching our event. it picks the requests based on FIFO (first in first out) principle.
-> so what does this event loop do? it's work is to watch over the event queue, and remove these requests one by one from the queue.
-> when a request is picked up from this queue, that request can be of two types: blocking operations (sync), and non-blocking operations (async). so what does this event loop do? it first checks whether this particular request is blocking or non-blocking operation.
-> if it's a non-blocking operation, event loop will pick it up, process it and sent the response to the user.
-> if it's a blocking operation, then to solve this particular request, this blocking operation goes to the thread pool (a pool which has all the threads), these threads are responsible to fulfill your blocking operation. i.e., a thread is assigned to every request.
-> this blocking operation requests the thread pool that i need a thread or a worker. so this thread pool will check is there any thread or worker available, as it has limited threads.
-> if a thread or a worker is available, then it will put it to work and when the work gets completed, then that worker will comeback in the thread pool and return the result, that result will be returned to us and we will send the response to the user.
crystall and clear
how event loop able to understand that the coming request is as blocking operaton/non-blocking operation
sir why blocking operations done directly and non-blocking operation went to thread pool??
For Non-Blocking or Async code , how it will work behind the scenese like how it will let other code to execute first and then it will execute at the end ??
learned you are real teacher
great video
wow great job bro .......
Great🎉❤
bro why are you so confused between non blocking and Blocking operations
Who's?
I think you are confused 😂
Good effort but sir confuses the both async and sync
For better clarification watch chai aur code/chai aur javascript/ Async vedio
Impressive!! The way of teaching is faboulous. Thanks for your effort . @piyush Garg
bro please share notes of the video in description , it helps us a lot.
Thank You Bhai
thanks a lot sir
if sync function uses thread of cpu to perform the tasks, what async function uses to perform a task?
Js is a single threaded so, how thread pool use 4 thread ?
Hello Piyush ji I want to ask one question that if node server is running with web socket server then at that time should there is any role of request of http blocking or non blocking?
Thanks Bro!
I was watching this series and on reaching this Video, i thought why i haven't subscribed n just subscribed the channel..and boom just saw the comment section 🤡😐😵💫💀
Dear Piyush its better to update this video
Regards
A happy Learner from your channel.
Do we not require worker threads for non blocking as well?
Node js is a single threaded..Then how it use multiple thread?
Event loop is responsible to make it multithreaded
Bro ,you are teaching wrong synchronous task of nodejs is only run in main thread , they dont utilize thread pool , thread pool is availble in libuv to do.........In Node.js, the thread pool is primarily available for handling certain types of asynchronous tasks, such as file system operations, network I/O, and cryptographic operations. It's important to note that the thread pool is not used for executing synchronous tasks; those tasks are executed on the main thread.
Yes correct, if the task is cpu extensive then only node will use the thread pool.
Yes and also thread pool size is not directly proportional to cpu cores. One core can handle many threads
Yes, Synchronous tasks are executed in main thread, and async tasks, event loop handles the async tasks, and then adds the callback fn in callback queue
Thankyou Sir
hello sir please tell me how
Will get to know this is block operation code or non blocking code
amazing
blocking will make use of threads to complete it task, synchronous are blocking code will stop the code there and do not allow execution to next line, then what is the point in having multiple threads when each blocking code do not allow other code to execute ("correct me if any wrong in my understanding")
thanks ❤
Thank you
As I know non blocking operation that is asynchronous operation gandle by thread pool
Hey Piyush, I have a question if nodeJS is single-threaded then how thread pool have 4 threads by default and we can increase it by increasing the number of CPU cores. Can you please help me here, I am quite confused.
Yeah That's true, It all depends on the capabilities of system OS / Core . If it is good the no of worker threads may increase or vice-versa. Also no of worker threads depends upon version of node js so there no thing as default. Also u can increase the no of workers manually although value depends of Capacity of core we are using
Hi piyush, can you please make a seperate dedicated video over this is quite confusing for me at a angle to me. like do we need to use async syntaxes for those blocking code so that the node will assign to another thread or once it understand itself that the code is a blocking code then it's decide to assign a new threads for that perticular task. does a single thread has it's own callstack. all this is confusing for me because I thought all tasks execute in call stack but you overview is quite differnt than the normal event loop concept the concept which says that engine execute line by line once it read the any async syntax it put it aside and start executing the it's sync tasks after all the sync tasks end the event loop then check for the task queue or the microtask queue then if there is any then then event loop will send it to the callstack to execute. but then where is the role of thread in this thoery? or if there is already a video could please share me a link?
we always says nodejs is single threaded, then how can have 4 threads?
yes i have same question
Gaming laptop PEEPS having 16 Threads / Workers
Sorry, but i learnt that in Node.js, the blocking (synchronous) operations are handled by the main thread, while the non-blocking (asynchronous) operations are offloaded to the thread pool.
You learnt right boy😅😅