Scenario 2:-> Mr. K isn’t happy with Synchronicity
Since Mr K is so efficient, he starts receiving many more calls. So what happens when you call him but he’s already busy talking to someone else? You won’t be able to ask him your question – not till he is free to receive your call. All you will hear is a busy tone.
So what can Mr K do to combat this?
Instead of taking calls directly:
- 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.
Now here lies the question: were the actions so far synchronous or asynchronous?
It’s mixed. When you left your message, Mr K wasn’t listening in to it, so the forth communication was asynchronous.
But, when he replied, you were there listening, which makes the return communication synchronous.
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…