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...
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
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.
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.
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 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.
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
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 ❤❤❤
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 ..
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
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."
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.
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.
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
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 !!
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.
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
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.
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.
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.
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 ??
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?
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?
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.
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
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
After all the confusing tutorials, I found the perfect tutorial to learn Node js
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.
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.
akheer kar diya....
bhout great
Ma Sha Allah
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
Wow sir
I wish I would have got this playlist earlier
Great Explaination
👏👏👏
You are the one who explain the things in a way to make one comprehend easily.
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 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.
Bro, amazing video with full clarity and increases curiosity to watch ur next videos, great work mate
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
Got a very good clarity. THANKS PIYUSH. Liked and Subscribed. Can we have more of these videos please, that should help in coding interviews!
Great Sir understood each line now i can also teach these topics to anyone😍
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
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 ..
I first like the lecture then poceed with watching it :)
You explained it very well. 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.
thank u sir ji
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
Understood everything very grateful for this amazing content.
Thank you Piyush bhai your lectures help a lot
great Lecture 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."
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.
this series is helpful ❤
Excellent video, this video will reach lakhs of views in future
Nicely explained sir
Thanks bhaiya, u really made it easy.
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.
well explained, thanks!
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
very good and easy way explain , i like it thanku
Beautiful explanation
Easy understood
Please react ki playlist bhi lekar aao..
Superb 🎉🎉
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 !!
Awesome lots of doubt clear !
Great explanation. Thank you
Good explanations I love it
Thanks bhaiya
learned you are real teacher
Amazing explanation Thank you so much
Great... Nice explanation
bhai tu mst pdata hia bro ❤❤❤❤❤❤❤❤❤❤
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.
Very well explained!
Thanks!
crystall and clear
Very good explanation
Amazing tutorials 🎉...
Very Useful
very easy explaination ever great
Good explanation. Liked it.
Good explaination.
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
can you please also make also videos on Mocha -Chai Framework .. you are brilliant ..:)
Good effort but sir confuses the both async and sync
For better clarification watch chai aur code/chai aur javascript/ Async vedio
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
Very good explanation ❤
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.
how event loop able to understand that the coming request is as blocking operaton/non-blocking operation
bro please share notes of the video in description , it helps us a lot.
Awesome ❤
Perfect 👌
thanku sir
Impressive!! The way of teaching is faboulous. Thanks for your effort . @piyush Garg
Thank You Bhai
thanks bhaiya
Thankyou Sir
it means non-blocking operations are recommended to use
??
Yes!
thanks a lot sir
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.
great video
if my cpu has 8 cores then it has 16 threads right? so why cant i use those 16 threads?
Thank you
wow great job bro .......
Thanks Bro!
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 ??
Node js is a single threaded..Then how it use multiple thread?
Event loop is responsible to make it multithreaded
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?
sir why blocking operations done directly and non-blocking operation went to thread pool??
Great🎉❤
thanks ❤
this video helpful
bro why are you so confused between non blocking and Blocking operations
Who's?
I think you are confused 😂
As I know non blocking operation that is asynchronous operation gandle by thread pool
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?
Do we not require worker threads for non blocking as well?
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
kya blocking ka mtlb async task or non-blocking ka mtlb sync task hota hai starting se aap yahi bol rhe the but last me aapne opposite kar diya
Nice
very important
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😅😅
if sync function uses thread of cpu to perform the tasks, what async function uses to perform a task?
vid-6 ✅
nyc specs...