Browser threads and processes

Processes and threads

process

Technically speaking, process is a dynamic execution process of a program with certain independent functions on a data set. It is an independent unit of the operating system for resource allocation and scheduling. It is the carrier of application program operation. A process is likened to a factory floor, representing a single task that a CPU can handle. At any one time, the CPU is always running one process and the other processes are not running.

thread

In early operating systems, there was no concept of a thread. A process was the smallest unit that could own resources and run independently, and the smallest unit of program execution.

Task scheduling adopts the preemptive scheduling method of time slice rotation, and process is the smallest unit of task scheduling. Each process has its own independent piece of memory, so that the memory address of each process is isolated from each other.

Later, with the development of the computer, the CPU requirements are higher and higher, the switching overhead between processes is larger, has been unable to meet the requirements of more and more complex programs.

Hence the invention of thread, thread is a single sequence control flow in program execution, is the smallest unit of program execution flow. Here, threads are compared to workers in a workshop, that is, a workshop can allow multiple workers to cooperate to complete a task.

The difference and relationship between processes and threads

  • A process is the smallest unit of resources allocated by the operating system, and a thread is the smallest unit of program execution.
  • A process consists of one or more threads, threads are different lines of code execution in a process;
  • Processes are independent of each other, but threads in the same process share program memory (including code snippets, data sets, heaps, etc.) and some process-level resources (such as open files and signals).
  • Scheduling and switching: Thread context switching is much faster than process context switching.


Multiprocess and multithreading

  • Multi-process: Multi-process means that two or more processes are allowed to run at the same time on the same computer system. The benefits of multiple processes are obvious. For example, you can listen to the song while opening the editor and typing code, and there is no interference between the editor and the process of the listening software.
  • Multithreading: A program that contains multiple execution streams. That is, a program can run multiple threads simultaneously to perform different tasks. That is, a single program is allowed to create multiple threads of parallel execution to complete their respective tasks.


Browser processes and threads

First open the browser, then shift + Esc to open Chrome’s Task Manager

There are only three processes:

  • Browser process (Browser process): The main browser process (responsible for coordination, control), only one. There are
    • Responsible for browser interface display and user interaction. Forward, backward, etc
    • Responsible for page management, creating and destroying other processes
    • Draw an in-memory Bitmap from the Renderer process onto the user interface
    • Network resource management, download, etc
  • GPU process: used for 3D drawing, etc. (can be disabled, and this is related to the Composite Layers of the page rendering process)
  • Renderer (multithreaded internally) : A browser Renderer (browser core) is created for each TAB opening. By default, each Tab page has one process and does not affect each other. The main function is page rendering, script execution, event processing and so on


Why do browsers multiprocess?

When browsers were first designed, the web pages were very simple and the resource usage of each page was very low, so it was possible for one process to handle multiple pages.

And then today, a lot of web pages are getting more and more complex. Browsers that put all web pages into one process face challenges in terms of robustness, responsiveness, and security.

If a TAB page crashes in your browser, it will cause other web apps to open. In addition, compared with threads, processes do not share resources and address space, so there will not be too many security issues. Because multiple threads share the same address space and resources, there will be complex security issues such as malicious modification or acquisition of unauthorized data between threads.


How does Browser process cooperate with Render process and GPU process?






The Browser engine corresponds to the Browser process, and the Rendering engine corresponds to the Render process. To open a TAB with the user, you can see that the Browser process is controlled first. Then let’s look at the Chromium multithreaded model:

  • The Browser process receives the user’s request, is first processed by the UI thread and passes the corresponding task to the IO thread, which randomly passes the task to the Render process.
  • Render process IO thread after a simple explanation to the Render thread, the Render thread receives the request, load the web page and Render the web page, which may need Browser process to obtain resources and GPU process to help Render, finally Render process will be the result of IO thread to Browser process;
  • The Browser process receives the results and draws them;


What processes the browser Render process (the browser kernel) has

GUI rendering thread

Responsible for rendering browser interfaces, parsing HTML, CSS, building DOM trees and RenderObject trees, layout and drawing, etc. Note that the GUI rendering thread and the JS engine thread are mutually exclusive, and the GUI thread will be suspended when the JS engine is executing. GUI updates are stored in a queue until the JS engine is idle and executed immediately.

JS engine thread

Also known as the JS kernel, it handles Javascript scripts. The JS engine thread is responsible for parsing Javascript scripts and running code. Is there only one JS thread running on a Tab page (renderer process) at any time

Also note that the GUI rendering thread and the JS engine thread are mutually exclusive, so if the JS execution takes too long, the page rendering will be incoherent and the page rendering load will block.

Event trigger thread

Belongs to the browser, not the JS engine, and is used to control the event loop.

When the JS engine executes a code block such as setTimeOut (or other threads from the browser kernel, such as mouse clicks, AJAX asynchronous requests, etc.), it adds the corresponding task to the event thread

When the corresponding event meets the trigger condition, the thread will add the event to the end of the queue, waiting for the JS engine to process. Note that due to the single thread of JS, the events in the queue must wait for the JS engine to process (when the JS engine is idle).

Timing trigger thread

Browser timing counters are not counted by JavaScript engines (because JavaScript engines are single-threaded, If the thread is in the blocking state, it will affect the timing accuracy.) Therefore, a separate thread is used to time and trigger the timing (when the timing is finished, it is added to the event queue, waiting for the JS engine to be idle.) Note that the W3C has stipulated in the HTML standard that setTimeout interval less than 4ms is counted as 4ms.

Asynchronous HTTP request threads

If a callback function is set, the asynchronous thread generates a state change event and places the callback in the event queue when the XMLHttpRequest detects a state change after the connection by opening a new thread request through the browser. It’s executed by the JavaScript engine.


JS engine threads

Why is JavaScript single threaded?

First, to clarify the concept, the JS engine thread lives in the Render process. In fact, the previous process, thread between the introduction has been understood, threads share resources and affect each other. Assume that javascript is running with two threads that manipulate the same resource from each other, which creates synchronization problems and changes to which one is the standard. So JavaScript is single-threaded, and that has become a core feature of the language and will not change in the future.

Does WebWorker cause JS multithreading?

<! DOCTYPEhtml>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>webWorker</title>
</head>
<body>
    <script>
        var worker = new Worker("worker.js");
        worker.postMessage(123456);

        worker.onmessage = function (e) {
            console.log(e.data)
        };
    </script>
</body>
</html>

Copy the code
//worker.js
onmessage = function (count) {
  console.log("web worker start")
 
    var i = 0;
 
    while(i < count.data) {
      i ++;
    }
 
    postMessage("web worker finish");
};
Copy the code






The result is that webworkers can execute code while the JS engine is executing code

Here we need to be clear at the beginning of the problem, whether the js execution is caused by multi-threading or the JS engine multi-threading. Here are two concepts. In the main column of the above illustration is the browser Render process (I guess), because during this process we can see the JS code executing, and also the GUI Render thread parsing the HTML code.

The multithreading of JS execution is still the multithreading of JS engine

I read a sentence on MDN: The Worker interface generates true OS level threads. So the Webworker here is not a new JS engine thread. It’s operating system level threads. The execution of the thread does not affect the execution of the original JS engine, nor does it affect the browser Render process. However, webworker does implement multi-threading of JS code execution (of course, these are my guesses based on the results I see, did not find the actual demonstration data, if you know can inform, thank you).

Therefore, my current conclusion is that Webworker can cause multi-threaded execution of JS code, but not multi-threaded execution of JS engine. The life cycle of Webwoker is controlled by the JS engine thread because WebWeoker provides a set of apis for us to operate on.

Then let’s talk about some of the things you can’t do with Webweoker: Again, for security reasons, concurrency can have an interesting effect on your code if you’re not too careful. However, for Web workers, the points of communication with other threads are carefully controlled, which means that you can hardly cause concurrency problems. So Webworker has its own restrictions (the following was found online because I don’t use Webworker in this way) :

  1. Read-only access to Location and Navigator that cannot access DOM and BOM objects, and navigator encapsulates as a WorkerNavigator object, changing some properties. Unable to read the local file system
  2. The communication between the child thread and the parent thread is through value copy. The modification of the communication content by the child thread does not affect the main thread. Excessively large values during communication can also affect performance (transferable objects can solve this problem)
  3. Not really multithreading, multithreading is because of the browser
  4. compatibility
  5. Because threads import external JS through importScripts and execute it directly, it is not safe to inject malicious code from outside
  6. Most browsers have a limit on the number of webworker threads that can be created. Although it can be expanded manually, if it is not set, it is generally less than 20 threads, each thread is about 5M, and some unused threads need to be closed manually before new threads can be created (related solution).
  7. Js has real thread things like SharedArrayBuffer

Js code execution (Event Loop) and cooperation between other threads

JavaScript engines don’t run on their own; they run in a host environment, which to most developers is usually a Web browser. Provides a mechanism to handle the execution of multiple blocks in a program, which can be interpreted as multiple callback functions, and calls the JavaScript engine on each block, called an event loop. In other words, the JavaScript engine itself has no concept of time, just an environment that executes arbitrary snippets of JavaScript code on demand. “Event” (JavaScript code execution) scheduling is always done by the environment that contains it. This schedule is scheduled by an event that triggers the thread.

For example, if your JavaScript program makes an Ajax request to fetch some data from the server, you set up the response code in a function (usually called a callback function), and the JavaScript engine informs the host environment (the event triggers the thread) : “Hey, NOW I’m going to pause execution and call this function as soon as you complete the network request and get the data.” The browser then sets up to listen for responses from the network, and when it gets the data for you, it inserts the callback function into the event loop to schedule the execution of the callback.

Take a look at the process/thread collaboration above for a page request and js execution.Processon original link.




The emergence of the Promise

<! DOCTYPE html><html lang="en">
<head>
    <meta charset="UTF-8">
    <title>webWorker</title>
</head>
<body>
    <script>
      setTimeout(function() {
        console.log('setTimeout run');
      }, 0);
 
        new Promise(function(resolve, reject) {
        resolve();
        })
        .then(function(){  
        console.log('promise run'); });</script>
</body>
</html>
Copy the code
promise run
setTimeout run
Copy the code

First, the JS engine has to execute the main thread JS code (it will finish first, because a JS load will be executed from the top down, js engine will have time to take out the code block from the event loop queue to execute). As for setTimeout, although the interval is 0ms, The actual execution is 4ms. And the callback function is placed in the event loop queue.

What about Promise? For example, if we are executing the main js thread, the JS engine will not immediately go to the event loop queue to execute the code block. Instead, it will say that the main thread still has something to do, which is a promise. The event granularity is different. Promsie is a task queue above the event loop queue.


Macrotasks and Microtasks

This is a concept in HTML Standard.

Macrotask and MicroTask are both asynchronous tasks. Let’s take a look at their apis:

  • macrotasks: setTimeout, setInterval, setImmediate, I/O, UI rendering
  • Microtasks: Process. nextTick, Promises, Object.observe(Disuse), MutationObserver

Macrotask will only extract one execution per event loop, while MicroTask will continue to extract until the MicroTasks queue empties

Event loop process model

Html.spec.whatwg.org/multipage/w…

With reference to

  • Blog.csdn.net/Steward2011…Segmentfault.com/a/119000001…
  • www.imweb.io/topic/58e3b…
  • www.ruanyifeng.com/blog/2014/1…
  • Segmentfault.com/a/119000000…
  • Juejin. Cn/post / 684490…