Callback Queue VS Microtask Queue

แชร์
ฝัง
  • เผยแพร่เมื่อ 17 พ.ย. 2020
  • In this lecture, you will learn what is Callback queue and Microtask Queue and which one takes the priority over another.
    A callback function can wait for its execution in any one of the queue i.e. callback queue or microtask queue and once the call stack is empty, event loop pushes the callback functions from these queues to call stack for there execution.
    Microtask queue takes priority over the callback queue and callback functions of Microtask queue are executed first. Once all the functions of callback queue are executed completely, then only callback functions of callback queue gets executed.

ความคิดเห็น • 41

  • @lokeshbajracharya5190
    @lokeshbajracharya5190 3 ปีที่แล้ว +2

    I dont know... im so happy with the javascript topics you are explaining.. subscribed
    Ps: i havent even watched one video yet..

  • @caizza3
    @caizza3 3 ปีที่แล้ว +2

    Beautiful explanation, probably the clearest and best precise explanation I've seen. Well done!

    • @procademy
      @procademy  3 ปีที่แล้ว

      Glad it was helpful!

  • @samartajshaikh2601
    @samartajshaikh2601 2 ปีที่แล้ว

    Thanks for explaining microtask queue and its purpose for existence in browser so well.

  • @krishangoel7491
    @krishangoel7491 3 ปีที่แล้ว

    Amazing video bro. I was searching for this kind of lecture from the last 2 years.

    • @procademy
      @procademy  3 ปีที่แล้ว +1

      Glad you liked it :)

  • @albertolopez7073
    @albertolopez7073 3 ปีที่แล้ว

    Thank you for this video, your diagrams helped a lot!!

    • @procademy
      @procademy  3 ปีที่แล้ว

      Glad it helped! :)

  • @SumitSingh-rw2vl
    @SumitSingh-rw2vl 2 หลายเดือนก่อน

    very helpful video but one more question what difference Callback Queue VS Microtask Queue

  • @full-stack2667
    @full-stack2667 2 ปีที่แล้ว

    Thank you very much dear for this simple explanation ☺

  • @BlaBlaBlaInDaHouse
    @BlaBlaBlaInDaHouse ปีที่แล้ว

    Great video, thank you for your explanation!

  • @piyushdanej3930
    @piyushdanej3930 3 ปีที่แล้ว

    really good explanation !

  • @vaaszimmer9004
    @vaaszimmer9004 2 ปีที่แล้ว +1

    Beautiful explanation

  • @NpcX-pn5xk
    @NpcX-pn5xk 2 ปีที่แล้ว

    Wow such a quality content, keep doing your awesome work man

  • @philipfuster5443
    @philipfuster5443 ปีที่แล้ว

    Very nice. Thank you

  • @eanewmahariel2279
    @eanewmahariel2279 3 ปีที่แล้ว +1

    my english is nicht gut, but it still so easy to understand what u explain! THANKS!

    • @procademy
      @procademy  3 ปีที่แล้ว

      Glad to hear that!

  • @PlanetJudy
    @PlanetJudy 2 ปีที่แล้ว +1

    Thanks!

  • @touseefahmad9794
    @touseefahmad9794 2 ปีที่แล้ว

    very Useful

  • @jkkbm
    @jkkbm ปีที่แล้ว

    Nice !

  • @yasirlambawala5255
    @yasirlambawala5255 ปีที่แล้ว

    can you make a video how async and await works in execution context

  • @WeskerUmbrella4
    @WeskerUmbrella4 2 ปีที่แล้ว +1

    I have a question, since I've seen conflicting information pop up in every article I read.
    When you talk about Global Execution Context (the *(anonymous)* function in V8 that always appears first on the Call Stack), that is our .js file that first executes, in order to create the "environment" for the code in that file. That part I understand.
    However, when you talk about the empty stack, doesn't that also mean that the *(anonymous)* function needs to be taken off the stack as well? Wouldn't that mean that the JS engine has reached the end of the file AND THEN started to check for the Microtask and Callback Queue in order to finish the waiting tasks?
    The part that's confusing to me is that your slides show the Global Execution Context still existing on the stack as the only function and therefore, the stack is considered "empty". While in some other explanations, I've seen even the *(anonymous)* function being popped off the stack AND THEN the stack is considered empty to start running the callbacks from both queues (priority first).
    What would be the correct explanation in this case?
    The Call Stack is empty when: the GEC is popped off (end of file) OR GEC is the only thing that remains (file is still running)?

    • @procademy
      @procademy  2 ปีที่แล้ว

      That's a very good question and I have covered this part already in one of the lectures.
      The global execution context is created as soon as the program starts executing. And it is popped off the call stack only when the program is stopped.
      If there is no code to execute in global scope, then also GEC will stay there in call stack. It will only pop off when the program has finished executing all code including callback functions.

    • @WeskerUmbrella4
      @WeskerUmbrella4 2 ปีที่แล้ว

      @@procademy Oh, I see.
      So our script isn't done executing AS LONG as there is still code to be run.
      Which means that if JS engine has reached the end of the file its running BUT if there are callbacks in the Callback and Microtask Queue waiting to be executed, then our GEC (our *anonymous* function [the entire file]) STILL cannot be removed from the stack. It needs to wait all for all callbacks to return to the stack in FIFO order (microtasks first then callback queue) to finish and when these two queues are emptied, then it can end execution of the file and pop off the stack.
      But this is that confusing part I was talking about.
      If the GEC isn't yet popped off the stack (the only item on the stack) as the JS engine has reached the end of the file AND there are callbacks in both queues waiting to be executed, wouldn't that mean that technically, call stack isn't empty? Or is the "empty stack" statement only used to describe it when every other stack frame is popped off the stack, THAT ISN'T Global Execution Context?
      On the side note, your videos are amazing.
      I know a fair amount of JS but the "behind the scenes" of it are still confusing to me. These videos definitely help in understanding how everything works, which will then help me write and understand code when I use different browser APIs for asynchronous code. You might see a few more of my comments about further questions on related topics 😊

  • @thimothy1213
    @thimothy1213 2 ปีที่แล้ว

    Have you also made video on Async - Await ?

  • @rahulkarjavkar7217
    @rahulkarjavkar7217 3 ปีที่แล้ว

    Is it possible to print "SetTime callback executed" before "Resolved promise data!"? as it takes more time to execute.

    • @procademy
      @procademy  2 ปีที่แล้ว

      Please share this channel with others if you like my videos...🤝🤝

  • @saikumar-eh6df
    @saikumar-eh6df 3 ปีที่แล้ว

    Is there any difference in the node.js event loop compared to the browser event loop? What are the nodejs API functions

    • @procademy
      @procademy  3 ปีที่แล้ว +2

      Both are quite different. Browser's event loop doesn't depends on I/O Operations. But Node js event loop depends on I/O operations. Here the Node js event loop main goal is to separate out the main process and try to execute I/O operations and other timer API's asynchronously.
      Its out of scope to talk about node js event loop here. But i will cover it in node JS course and there i will also cover Node JS APIs :)

    • @saikumar-eh6df
      @saikumar-eh6df 3 ปีที่แล้ว

      @@procademy ok. thank you

  • @marwenlabidi_dev
    @marwenlabidi_dev 3 ปีที่แล้ว +1

    What if u warp a setTime function inside a promise ?

    • @procademy
      @procademy  2 ปีที่แล้ว

      Please share this channel with others if you like my videos...🤝🤝

  • @kevinnakandakare2300
    @kevinnakandakare2300 3 ปีที่แล้ว +1

    hi, I have a question, is this event loop the same for Node.js?

    • @procademy
      @procademy  3 ปีที่แล้ว

      The Nodejs event loop is implemented differently than the browser based event loop.
      While Nodejs uses the Google's V8 engine as it's runtime, it does not use V8 to implement the event loop.

    • @procademy
      @procademy  2 ปีที่แล้ว

      Please share this channel with others if you like my videos...🤝🤝

  • @abhishekghimire3101
    @abhishekghimire3101 3 ปีที่แล้ว +1

    who pushes global execution context to call stack ??is it JS Engine?

    • @procademy
      @procademy  3 ปีที่แล้ว

      That's right. When the program is compiled and start executing, JavaScript engine creates a global execution context in the call stack where all top level codes get stored and executed.
      Please watch my playlist "How JavaScript works behind the scenes" to understand it better.

    • @procademy
      @procademy  2 ปีที่แล้ว

      Please share this channel with others if you like my videos...🤝🤝

  • @krishangoel7491
    @krishangoel7491 3 ปีที่แล้ว

    const promise1 = new Promise((resolve, reject) => {
    console.log(1)
    resolve('resolve1')
    })
    const promise2 = promise1.then(res => {
    console.log(res)
    })
    console.log('promise1:', promise1);
    console.log('promise2:', promise2);
    o/p
    1
    "promise1:", [object Promise] { ... }
    "promise2:", [object Promise] { ... }
    "resolve1"
    So my question is my why console.log(1) print first?

    • @procademy
      @procademy  3 ปีที่แล้ว

      That's because, the handler function of promise1 will be executed and first it will log 1 then it will return the promised data from there.
      Hope it make sense.

  • @xiaoranlr
    @xiaoranlr ปีที่แล้ว +1

    The explanation is not correct.