From settimeout to browser threading mechanism, the effect of simultaneous JS threading and UI implementation

Encounter a problem condition:

OCX reads the result set of multiple records.

Use for traversal in JS.

for (var i= 0;i<length;i++) {

$.ajax ({

Background return results

Processing success,

Call the method that updates the progress bar.

})

}

found that the progress bar control is always rendered only when the for-all traversal is complete. Change the style.

After reviewing n multiple data changes,

Change for recursive call, do not execute once, render a progress bar, after the JS code in settimeout (function,0), then the browser will first render the UI interface, and then after the execution of the JS code, the implementation of the progress bar real-time update.

Update the data for the progress bar
Run (size,a+1);
if (a<size-1) {
++a;
Let the JS thread wait for 100 and wait for the UI rendering process to be implemented
setTimeout (submitdata,10);
SubmitData ();
}else{
size = 0;
A= 0;
return;
}

Problem-solving knowledge points: from settimeout to browser threading mechanism

We know there are at least two threads inside the browser: parsing the JS thread and rendering the interface thread. Here we call them the JS thread and the UI thread.

Since JS is a manipulation of the DOM, the element data obtained before and after the render thread may be inconsistent if you modify these element properties to render the interface simultaneously (that is, the JS thread and the UI thread run concurrently). Therefore, in order to prevent the rendering from unpredictable results, the browser controls the JS thread and the UI thread to execute synchronously in a queued form.

settimeout Execution will open a new timer thread, which is exactly in the JS thread running, when the JS thread execution completes, found that settimeout will start execution immediately (that is, time is less than the above critical value), To avoid the bad experience of settimeout when the UI thread is running too long, the browser chooses to wait until settimeout expires and then runs the JS inside. If the settimeout is found to expire longer, the browser chooses to switch to the UI thread immediately to avoid wasting time.

Conclusion: SetTimeout can be used to process time-consuming JS code, but be careful not to set the second parameter too small, otherwise you will see a blank page. Recommended at around 100ms to meet all browsers. Of course, if can not be compatible with IE, abandon settimeout bar, web workers will be a good choice.

From settimeout to browser threading mechanism, the effect of simultaneous JS threading and UI implementation