Javascript thread and Timing Mechanism

This article mainly introduces the relevant information about Javascript threads and timing mechanisms. For more information about coders, see. Use of setTimeout and setInterval

In the Javascript api documentation, the second parameter setTimeout and setInterval are defined to indicate the number of milliseconds between which the callback function is executed and the number of milliseconds at which the callback function is executed. However, with the accumulation of work experience, we find that this is not the case.

For example:

p.onclick=function(){  setTimeout(function(){     document.getElementById('input').focus();   },0);}

You can't get through the explanation, and immediately execute the task. Why do you need to set a regular circle.

One day you wrote the following code

SetTimeout (function () {while (true) {}}, 100); setTimeout (function () {alert ('ert ') ;}, 200 );

The first line of code has an endless loop, causing the second line of alert to never appear. Why?

Single thread or multi-thread?
Originally, the Javascript engine runs in a single thread, and the browser only has one thread running JavaScript programs. Because of the single-threaded design, complicated multi-threaded synchronization issues are eliminated.

When you set a timer, the browser inserts the callback function you specified into the task sequence after the set time, instead of executing it immediately. If the scheduled time is set to 0, it indicates that the task sequence is inserted immediately, instead of being executed immediately. You can only execute the task after it is finished in the queue.

So the following code first pops up 2, then 1

setTimeout(function(){  alert(1);},0);alert(2);

So what is the actual purpose of this? See the following example.

      
      
      SetTimeout 0    Input characters, but the content cannot be displayed in real time 
Input characters. The content can be displayed in real time.    
Script function show (val) {document. getElementsByTagName ("p") [0]. innerHTML = val;} script

In this example, the js engine needs to execute the keydown event handler and then update the value of the input box. When the event handler executes, the task that updates the value can only wait in the queue, so the updated value cannot be obtained when the keydown event is executed. However, through setTimeout, we put the value-taking operation into the queue, it is executed after the value is updated, so the content can be displayed in real time.

Let's take a look at the following code:

setTimeout(function(){  //do something...   setTimeout(arguments.callee,10);},10); setInterval(function(){  //do something...},10);

The two codes seem to have the same effect, isn't they. In fact, there is a difference. the setTimeout In the callback function in the first section is a new timer set after the js engine is executed, it is assumed that the last callback is an interval from processing to the next Callback. The theoretical interval is greater than or equal to 10 ms, and the subsequent code is less than or equal to 10 ms.

Speaking of this, is XMLHttpRequest really asynchronous? Yes, the request is asynchronous, but this request is a new thread in the browser. When the Request status changes, if a callback has been previously set, the asynchronous thread puts the status change event into the js engine processing queue for medium waiting for processing, when a task is processed, the js engine always executes the function set by onreadystatechange in a single thread.