In Threads and Processes we talked about why we need processes and why we need threads. So what are the processes and threads in the browser, and what does it do? This section gives an overview of browser threads and processes and their respective roles.

In the browser, there are the following processes:

  1. Process of GPU. The browser has only one process globally. It has to do with graphics rendering.

  2. Other plugin processes, like if you install a plugin for your browser, that plugin is a process.

  3. Browser process: the main process of the Browser (responsible for coordination and control), there is only one. The main functions are as follows:

    • Responsible for browser interface display and user interaction. Forward, backward, etc
    • Responsible for page management, creating and destroying other processes

  4. The browser renderer process, also known as the browser kernel. Categories are:

    Google Chrom: WebKit is still used in the release notes for Chrome 28, but has been replaced with Blink since Chrome 28.0.1469.0.

    **Internet Explorer: Trident kernel, also known as IE kernel

    Mozilla Firefox: Gecko kernel, commonly known as the Firefox kernel.

    Safari: its

    Opera: Originally its own Presto kernel, later Webkit, and now Blink kernel

In the above process, we need to be concerned about the process is: browser rendering process, his main role is: responsible for page rendering, script execution, time processing, network requests and other functions.

Browser rendering process

In a process, there is at least one thread. A thread is known as the minimum unit of execution for CPU task scheduling. In the browser rendering process, there are the following threads:

  1. GUI rendering thread: Parsing HTML documents, generating DOM trees and CSS trees (note that CSS trees do not block DOM tree generation). After the DOM and CSS trees are generated, a render tree is generated based on these two numbers. At this point both sides will block each other), and render the render tree onto the interface.

  2. JS thread: Used to execute JS code. See JS running process for details

  3. Timer thread: Used to process the timer thread, when the timer expires, the callback into the task queue, waiting for the JS thread to execute. So with JS threads, why do we need timer threads? Look at the following code explanation:

    function test() {
  setTimeout(() = > {
  console.log('I'm timer one.');
}, 1000);
  setTimeout(() = > {
      console.log('This is timer two.');
}, 2000);
  
};
test();
Copy the code

    If there is no timer thread, and JS is single threaded, I have to push it one by one, then timer 1 is pushed first, and timer 2 is pushed next. But because the time of timer 1 is less than the time of timer 2, timer 1 should go off the stack first. But because the stack is a first in, last out data structure. So this conflicts with the definition of the stack. Because timer 2 is not out of the stack, timer 1 cannot be out of the stack.

  4. The event triggers the thread. Used to manage event triggers, such as click events, mouse movement events. When these events are triggered, the callback of these events is added to the task queue, waiting for JS to execute.

  5. Asynchronous HTTP request threads. A thread that XMLHttpRequest starts after a connection. If the thread detects a change in the state of the request, if a callback function is set, the thread adds the callback function to the event queue until the JS engine is free to execute.

Why JS threads and GUI threads are mutually exclusive

The main reason is that when a document is loading, if the JS thread is also loading and executing, for example, to obtain a node with the ID of DEMO1, at this point in our rendering process, the render tree has not been generated, so the layout and rendering will not be carried out. So this node doesn’t exist at this point, so you definitely can’t find it. So to avoid this, in the browser, the JS line layer and the GUI thread are mutually exclusive, and when one executes, the other is forced to suspend. This leads to the problem that when JS executes an algorithm with a very high time complexity, the GUI rendering thread is suspended for too long because the execution is delayed, causing the page to look stutter and the event response to be slow. The solution can be solved through the Web Worker.