You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Notes/16-Async-EventLoops.md
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ console.log("End"); // calls console api and logs in console window. After this
36
36
37
37
### Event Loops and Callback Queue
38
38
- cb() cannot simply directly go to callstack to be execeuted. It goes through the callback queue when timer expires.
39
-
- Event loop checks the callback queue, and if it has element puts it into call stack. It is a *gate keeper*
39
+
- Event loop checks the callback queue, and if it has element puts it into call stack. It is a *gate keeper*.
40
40
- Now cb() in callstack is run. Console API is used and log printed
41
41
42
42
Final console output:
@@ -102,11 +102,12 @@ Callback Queue to enter Call Stack.
102
102
103
103
- If the task in microtask Queue keeps creating new tasks in the queue, element in callback queue never gets chance to be run. This is called **starvation**
104
104
105
+
### Some Important Questions
105
106
107
+
1.**When does the event loop actually start ? -** Event loop, as the name suggests, is a single-thread, loop that is *almost infinite*. It's always running and doing its job.
106
108
109
+
2.**Are only asynchronous web api callbacks are registered in web api environment? -** YES, the synchronous callback functions like what we pass inside map, filter and reduce aren't registered in the Web API environment. It's just those async callback functions which go through all this.
107
110
111
+
3.**Does the web API environment stores only the callback function and pushes the same callback to queue/microtask queue? -** Yes, the callback functions are stored, and a reference is scheduled in the queues. Moreover, in the case of event listeners(for example click handlers), the original callbacks stay in the web API environment forever, that's why it's adviced to explicitly remove the listeners when not in use so that the garbage collector does its job.
108
112
109
-
110
-
111
-
112
-
113
+
4.**How does it matter if we delay for setTimeout would be 0ms. Then callback will move to queue without any wait ? -** No, there are trust issues with setTimeout() 😅. The callback function needs to wait until the Call Stack is empty. So the 0 ms callback might have to wait for 100ms also if the stack is busy.
0 commit comments