Which one have more preference to the execution context setTimeout(()) or Promise in event loop?
2 Likes
I think Promise would have more preference. In JavaScript, we have 1 call stack, 1 web API container, and a microtask queue.
By default, setTimeout() is considered as the WebAPI, hence go to Web API container to get resolved, while Promises are meant to be resolved through Microtask Queue. And by default, the Microtask queue is resolved first, then webapi container.
Example-
A- SetTimeout()
B- Promise
Step-1-
Call stack- [A,B];
Step-2
Call stack- [B];
WebAPI container- [A];
Step-3 -
Call Stack- []
WebAPI container- [A];
Microtask Queue- [B];
Now, both A and B wants to get fully executed, right?
Since microtask has higher priority- B would get resolved first (which was a promise)
Now, how A would get resolved? When the time finishes of setTimeout, it goes to the microtask queue, then get executed completely
From WebAPI container- [A] —> microtask queue[A] ----> executed completely.
That’s what event loop in JS is. So Promise>SetTimeout.
Do like if you understand
1 Like
@atulfebe
In the event loop of JavaScript, setTimeout() and Promises are both tasks that are queued for execution in the future, but they have different priorities and execution order.
In general, Promises have a higher priority than setTimeout() tasks because they are part of the microtask queue, which is executed before the macrotask queue that includes setTimeout().
When the main thread of execution is idle and there are tasks waiting in both the microtask and macrotask queues, the event loop will first execute all the tasks in the microtask queue before moving on to the macrotask queue. This means that any Promises that have been resolved and added to the microtask queue will be executed before any setTimeout() tasks that are waiting in the macrotask queue.
However, it’s important to note that the execution of a setTimeout() task can still be affected by other factors such as the minimum delay specified in the setTimeout() call, the load on the system, and the overall performance of the code.
1 Like
@rrnayak2609 As much as I understand, you are saying setTimeout will go to macrotask queue. But, according to me, we can’t say it a queue. Because Queue is FIFO. So suppose we have 2 setTimeout A and B, A pushed first with timeout of 10 second, and B with a timeout of 3 second.
If you say it is as queue, even after timer expired for B, it will still wait because A to complete is still on the front of queue. So, excution flow will A then B but in actual B then A will happen as per me.
That’s why setTimeout things are handled by V8 engine, not by JS. And V8 engine considers it as Web API and send it to web API area. Where anything which is resolved first, will get pushed to microtask queue.
Reference- https://www.javascripttutorial.net/javascript-bom/javascript-settimeout/#:~:text=The%20setTimeout()%20executes%20and%20creates%20a%20timer%20in%20the%20Web%20APIs
2 Likes
@rhythm
You are correct in saying that setTimeout and other asynchronous tasks in JavaScript are not strictly managed by a FIFO (first in, first out) queue. While the event loop does work on the principle of processing the oldest task in the queue, the nature of asynchronous tasks means that they are not necessarily processed in the order in which they were added to the queue.
When you call setTimeout with a callback function and a timeout value, the browser sets a timer for that value and pushes the callback function to the macrotask queue when the timer expires. However, there is no guarantee that the macrotask queue will always be processed in strict FIFO order. If there are other tasks in the queue that take a longer time to complete, they may be processed before the setTimeout callback function, even if the timer has already expired.
That being said, you are also correct in saying that setTimeout and other asynchronous tasks are handled by the browser’s Web API, and not directly by the JavaScript engine. When the timer expires, the Web API signals the event loop that the task is ready to be processed. The event loop then schedules the task to be added to the macrotask queue, which will be processed when the current execution context has completed.
It’s also worth noting that the behavior of setTimeout can vary depending on the environment in which it is running. For example, Node.js and browsers may handle asynchronous tasks differently, and some browsers may use different threading models that affect how tasks are queued and processed.
1 Like