Where Async function is being executed? is it in execution stack or callback queue

My doubt is too simple. all sync JavaScript code is executed in execution stack . all async JavaScript callback function is placed in callback queue . event loop will wait to put callback functions into execution stack from callback queue until when execution stack gets empty.( to get execution stack empty, all of the sync code should be completed its execution)

i have a api call. for that I use async code. so my callback function which call api will be put in callback queue. is that callback function which call api will get executed in callback queue or execution stack?
even if java Script is single threaded language, it use multiple thread to complete execution for async function. system has many thread like network thread, i/o like that. To use this multi thread, I belive

When an async call is made, its entire stack is saved in the callback queue until the call completes. When this happens, the stack is moved back out of the queue and becomes the current execution stack. No code actually executes “in the queue”, it’s always executed in the context of the currently scheduled activation stack (also known as the “main thread”).

Does that answer your question?

1 Like

Yes you answered my question!
In my backend server created by using node.js i have get http request which has been accessed by two user A and B . user A hit the server first then user B hit server. This is a asyn request. As soon as user A hit server, the callback function for User A will be put in callback queue, then user B hit server , callback function for B will be in callback queue
Now callaback queue look like [a,b]. Just imagine that my call stack or execution stack is not empty. Some of blocking operation has to be finished until then user A and User B will be callback queue. My doubt is that whether user B has to wait till then completion of execution of A could be completed

If B’s async task completes before A’s does, then it will run before A, it doesn’t have to wait. The “queue” is actually a priority queue, so async tasks that are ready to run again will be given a priority that moves them to the front of the queue, ahead of the others that haven’t completed yet, and behind any others that have also become ready to run.

That’s how it logically works anyway: whether the JS engine actually uses a priority queue or not is an invisible detail (the V8 engine that Node runs on uses the operating system’s internal event mechanisms which are much faster than just scanning over a queue)

1 Like

If async tasks of B has to be completed before, then B has to be executed somewhere else. But the execution can be completed only in call stack! Isn’t? Then how can B be moved infront of Queue

 setTimeout (()=>{

return 2

This callback function will be placed in callaback queue. After 0 milliseconds it will be placed back into call stack. Is the value of that callback function 2 or undefined before getting started execution of call back function in call stack?

The execution of JavaScript code only completes in a thread, but things like reading files or reading/writing from the network happen “in the background”, outside of JS’s normal flow of control. Promises and async/await are how those kind of background processes are synchronized back to JS’s main thread.

1 Like

To perform execution of such networking operation or I/O operation it use system thread. Once that operation is completed , it will be moved into the front of the queue. Actually this is a blocking operation. If i have a function which has to complete i/o operation , it has to use system thread. Then that callback function will be completed its I/O operation before placing into call stack, am i right?

Yep, that’s how it works. When an async task gets blocked on I/O, it gets moved onto the system thread, which runs at the same time as the main thread, and runs all I/O simultaneously (using the OS’s scheduling primitives). When the I/O completes, it gets put back onto the queue with a “ready” priority, where it will then get de-queued and scheduled on the main thread again. Usually you don’t have to worry about that detail, you just know that the I/O will happen “in the background”, and that it will wake your task when it’s ready.

1 Like

I got a clarity. Then one more doubt. The callback function which has to do i/o operation can be completed by using system thread. Anyidea how the callback function which is in callaback queue access system thread. Is that being done by multiplexer. Will that call back function move first from callback queue to system thread and it will put back into in front of callback Queue from system thread as soon as it get finished it i/o operation ? This is the only one point i have to get clarity!

When an I/O operation completes, the callback gets put onto the queue ahead of any tasks that are still waiting for I/O and behind any others that have already completed and are just waiting to resume again. This is actually just a simplified view of scheduling, because there is probably some priority balancing going on as well.

I’m not familiar enough with how node multiplexes the I/O operations, but a quick glance at the node docs suggests that it’s using libuv, which uses different mechanisms depending on the OS. To find out more of the details of how Node schedules tasks, you’ll need to dive into documentation on its internals. This looks like a good place to start:

1 Like

I understood it very well. I have read about libuv which use for flatform indipendent i/o operation. The moment you said preority queue, i got more clarity. You helped me a lot to connect all of async operation how it works. Thank you so much for your time.