5

So i came up with this example and i cant understand why the setTimeout with 0 seconds is the last one to be executed

function waitThreeSeconds() {
  setTimeout(function() {
    console.log("Finished Function");
  }, 0);
}

function clickHandler() {
  console.log("Clicked");
}

document.addEventListener('click', clickHandler);

waitThreeSeconds();

//waiting 5 seconds 
var ms = 5000 + new Date().getTime();
while (new Date() < ms) {}


console.log('Finished Execution');

If its true that the setTimeouts callback is added to the queue why is it that everytime i do a click event it is added to the queue earlier then the callback for the setTimeout. That is until the Global Execution Context ('main') is popped off the stack

Randy Casburn
  • 13,840
  • 1
  • 16
  • 31
Tenzin Choklang
  • 504
  • 1
  • 5
  • 21
  • 1
    This says [that it won't execute the timeout until the main thread finishes](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout#Reasons_for_delays_longer_than_specified), if I understand it correctly. – Ken Y-N Nov 21 '18 at 04:52
  • yes i added the 5 sec while loop so that there can be a build up in the queue if that makes sense. All the call backs would be waiting in the queue. my question is why is the callback from setTimeout the last to occur – Tenzin Choklang Nov 21 '18 at 04:55
  • 1
    `while (new Date() < ms) {}` is a busy loop, while it's running nothing else can – Nick is tired Nov 21 '18 at 04:56
  • Perhaps also from the same resource: _Currently-executing code must complete before functions on the queue are executed, thus the resulting execution order may not be as expected._ – Randy Casburn Nov 21 '18 at 04:56
  • if nothing else can, then why are all my clicks registering in the queue @NickA – Tenzin Choklang Nov 21 '18 at 04:57
  • The clicks are queued by the browser. Maybe it can do that while your busy loop is still running. (just queue them, not call them) – Thilo Nov 21 '18 at 05:00
  • 2
    I don't know about JavaScript, but in many windowing models user inputs are high-priority events and timer events are very low priority that tend only to be served after all other pending events are handled. – Ken Y-N Nov 21 '18 at 05:00
  • can anyone confirm what @KenY-N stated? – Tenzin Choklang Nov 21 '18 at 05:05
  • JS does not run code concurrently. This protects you from race conditions. Whichever function is running must finish before another one can run. So a function that was scheduled to run will have to wait. – Chris Rollins Nov 21 '18 at 05:56

2 Answers2

0

Yes it's true what @KenY-N stated in question comment.

I answered this before in regards promise call backs (https://stackoverflow.com/a/40882544/5217142):

In HTML terms, the event loop for a page or set of pages from the same domain can have multiple task queues. Tasks from the same task source always go into the same queue, with the browser choosing which task queue to use next.

Tasks to run timer call backs come from the timer task source and go in the same queue....

The difference here is that you're asking if the task queue priority of click events is higher than that of timer call backs.

By inspection your code shows the answer is yes: the task queue for click events has priority over the task queue for timer call backs in the browsers you've tried.

traktor
  • 17,588
  • 4
  • 32
  • 53
0

Its because of event loop, every event of javascript came under a stack which it follow to execute processes , registering settimeout 0 , made in stand in que where it will execute when event loop will complete rest other task in waiting.

For ref please see this amazing explanation by : Philip roberts

https://www.youtube.com/watch?v=8aGhZQkoFbQ&vl=en

Shyam Tayal
  • 486
  • 2
  • 13