Let’s understand with an example. We’ll get help from Mr. K,
Scenario 1:-> Mr. K is trying Synchronicity
- Mr K is someone who can answer tough questions, and carry out any requested task.
- The only way to contact him is through a phone call.
- Whatever question or task you got, in order to ask Mr K’s help to carry it out; you call him.
- Mr K gives you the answer or completes the task right away, and lets you know it’s done.
- You put down the receiver feeling content and go out on a date.
Scenario 2:-> Mr. K isn’t happy with Synchronicity
So what can Mr K do to combat this?
- Mr K hires a new guy, Mr J and gives him an answering machine for the callers to leave messages.
- Mr J’s job is to pass on a message from the answering machine to Mr K once he knows Mr K has completely finished processing all previous messages and is already free to take a new one.
- So now when you call him, instead of getting a busy tone, you get to leave a message for Mr K, then wait for him to call you back (no date time yet).
- Once Mr K is done with all the queued up messages he received before yours, he will look into your issue, and call you back to give you an answer.
The call stack holds the frame of the initial function being called, and any other frames for functions called via nested calls on top of it .
When a message joins the queue, it waits until the call stack is empty of all frames from the previous message, and when it is, the event-loop de-queues the previous message, and adds the corresponding frames of the current message to the call stack.
The message waits again until the call stack becomes empty of its own corresponding frames (i.e. the executions of all the stacked functions are over), then is de-queued.
Consider the following code:
The function being run is baz() (at the last row of the code snippet), for which a message is added to the queue, and when the event-loop picks it up, the call stack starts stacking frames for baz(), bar(), and foo() at the relevant points of execution.
|Push action in Call Stack|
Once the execution of the functions is complete one by one, their frames are removed from the call stack, while the message is still waiting in the queue, until baz() is popped from the stack.
|Pop Action in Call Stack|
But what about the specific asynchronous methods?
So far I’ve not touched on APIs such as setTimeout() and AJAX, those are the ones that are specifically referred to as asynchronous. Why is that?
Remember, I told you the message didn’t leave until the call stack was empty of its corresponding frames, just like you didn’t leave on a date until you got your answer — that’s being synchronous, you are there waiting until the task is complete, and you get the answer.
Waiting isn’t ideal in all scenarios. What if after leaving a message, instead of waiting, you can leave on the date? What if a function can retire (emptying the call stack), and its message can be de-queued even before the task of the function is complete? What if you can have code executed asynchronously?
This is where APIs such as setTimeout() and AJAX come into the picture, and what they do is… hold on, I can’t explain this without going back to Mr K, which we’ll see in the second part of this article. Stay tuned…