Architectural evolution of browsers

Processes and threads

In the case of processes and threads, threads are simply units that perform tasks, while processes manage and start threads.

We can understand that a process is a running instance of a program. When we start a program, the operating system creates a block of memory for the program to hold code, running data, and a main thread to perform tasks. We call such a running environment a process.

Here is a brief introduction to single-threaded versus multi-threaded. Before we understand single-threaded versus multi-threaded, let’s first understand what parallel processing is.

Parallel processing in computers is processing multiple tasks at the same time. For example, we want to evaluate the values of the following three expressions and display the results.

A = 1+2
B = 20/5
C = 7*8
Copy the code

When writing code, we can break this process down into four tasks:

  • Task 1 is to calculate A=1+2;
  • Task 2 is to calculate B=20/5;
  • Task 3 is to calculate C=7*8;
  • Task 4 is to display the result of the final calculation.

Normally a program can be processed using a single thread, that is, each of the four tasks is executed in four steps in sequence.

With multithreading, we can do it in two steps: first, use three threads to perform the first three tasks simultaneously; Second, perform the fourth display task.

By comparison, you can see that it takes four steps to execute with a single thread, compared to two steps with multiple threads. Therefore, using parallel processing can greatly improve performance.

For a better understanding, please refer to the chart below.

If this still doesn’t make sense, consider the following example.

In the following function we use await, so the execution is sequential, and the second request will be initiated only after the information from the first interface is returned, so the total request time is the sum of three requests.

async request() {
    const a = await axios.get('xxx');
    const b = await axios.get('yyy');
    const c = await axios.get('zzz');
}
Copy the code

As an example of multi-threading, in the following code we use promise. all to make three simultaneous requests, and the network process will open three request threads to handle the corresponding tasks, so that the overall request time is the longest of the three times.

const a = axios.get('xxx');
const b = axios.get('yyy');
const c = axios.get('zzz');
Promise.all([a,b,c]);
Copy the code

In summary, the relationship between processes and threads has the following four points.

  • The failure of any thread in the process will cause the entire process to crash.
A = 1+2
B = 20/0
C = 7*8
Copy the code

When calculating the value of B, I changed the denominator of the expression to 0. When the thread executes B = 20/0, the thread will fail to execute because the denominator is 0, which will cause the whole process to crash. Of course, the results of the execution of the other two threads are also lost.

  • Threads share data in a process.

As can be seen from the figure above, thread 1, thread 2, and thread 3 write the execution results to A, B, and C, respectively. Then thread 2 continues to read data from A, B, and C to display the execution results.

  • When a process is shut down, the operating system reclaims the memory occupied by the process.

When a process exits, the operating system reclaims all the resources applied for by the process. Even if any of these threads leak memory due to improper operation, the memory will be properly reclaimed when the process exits.

  • The contents of the processes are isolated from each other.

Process isolation is A technique to protect each process from interfering with each other in the operating system. Each process can access only the data it owns, preventing process A from writing data to process B. Because data between processes is strictly isolated, a crash or hang of one process does not affect other processes. If there is a need for data communication between processes, then a mechanism for interprocess communication (IPC) is needed.

Single-process browser era

Single-process browser means that all the functional modules of the browser run in the same process. These modules include the network, plug-ins, JavaScript runtime environment, rendering engine and pages. Until 2007, all browsers were single-process. The architecture of the single-process browser is shown below:

Disadvantages of single-process browsers

  • unstable

Early browsers used plug-ins for video (Flash?). And so on a variety of powerful functions, we have said that any thread in the process of execution error, will lead to the collapse of the whole process. The crash of the plug-in will crash the entire browser. Imagine having multiple tabs open and writing emails all afternoon. The browser crashes because of a bug in a plugin, and the web version of email does not provide temporary storage.

  • Not smooth

All page rendering modules, JavaScript execution environments, and plug-ins run in the same thread, which means that only one module can be executed at a time. If there is one place where the code runs too long, or even creates an infinite loop, it will cause other subsequent processes to execute.

  • unsafe

This can be analyzed in terms of plug-ins and page scripts. Plug-ins can be written using C/C++ code, through plug-ins can obtain any resources of the operating system, when you run a plug-in in the page also means that the plug-in can fully operate your computer. If it’s a malicious plug-in, it can release a virus, steal your passwords and raise security issues.

As for page scripts, they can gain access to the system through a vulnerability in the browser, and they can also do malicious things to your computer, which can also cause security problems.

Current multi-process architecture

  • Browser process. It is mainly responsible for interface display, user interaction, sub-process management, and storage.
  • Render process. The core task is to turn HTML, CSS, and JavaScript into web pages that users can interact with. Both the typography engine Blink and JavaScript engine V8 run in this process. By default, Chrome creates a rendering process for each Tab Tab. For security reasons, renderers are run in sandbox mode.
  • Process of GPU. In fact, Chrome didn’t have a GPU process when it was first released. The original intention of using GPU was to achieve 3D CSS effect, but later the UI interface of web page and Chrome were drawn on GPU, which made GPU become a common requirement of browser. Finally, Chrome has introduced GPU processes on top of its multi-process architecture.
  • Network process. It is responsible for loading web resources on the page. It used to run as a module in the browser process until recently, when it became a separate process.
  • Plug-in process. It is mainly responsible for the running of plug-ins. Plug-ins are prone to crash. Therefore, plug-ins need to be isolated through the plug-in process to ensure that the plug-in process crash does not affect the browser and page.

Let’s examine how current multi-process architectures address the shortcomings of single-process architectures.

  • Is not stable. Processes are isolated from each other, so when a page or plug-in crashes, it only affects the current page or plug-in process, not the browser and other pages, which perfectly solves the problem that a page or plug-in crash can cause the entire browser to crash, which is unstable.
  • Not smooth. Also, JavaScript runs in the renderer process, so even if JavaScript blocks the renderer process, it only affects the current rendering page, not the browser and other pages, whose scripts are running in their own renderer process. So when we run the script in Chrome, the only thing that doesn’t respond is the current page. The solution to the memory leak is even easier, because when a page is closed, the entire rendering process is closed, and the memory occupied by the process is then reclaimed by the system, which can easily solve the memory leak problem of the browser page.
  • Not safe. An added benefit of the multi-process architecture is the use of a secure sandbox, which you can think of as a lock placed on the process by the operating system. Programs in the sandbox can run, but they cannot write any data to your hard drive or read any data from sensitive locations, such as your documents and desktop. Chrome locks the plugin and renderer processes in a sandbox, so that even if a malicious program is executed in the renderer or renderer process, the malicious program cannot break through the sandbox to obtain system permissions.

Histories make men wise; poets witty; the mathematics subtle; natural philosophy deep; moral grave; logic and rhetoric able to contend.

In: How browsers work and practice