The browser’s multi-process architecture works with multiple threads
The browser’s multi-process architecture doesn’t seem to work with multiple threads. But as the first man in the fishpond, can you only see the surface of the problem? Can’t. To understand it in depth, understand why the browser uses a multi-process architecture to work with multiple threads.
Multiprocess architecture
What is a process?
A process is the basic unit by which the CPU allocates resources. Process A does not use the same amount of memory as process B.
Why do you need a multi-process architecture?
Suppose one day you open station P and are watching the teacher solve the problem to the key part. The page suddenly crashed. Investigate its reason is you another page open B site crash. Do you think you’ll break down? Therefore, browsers need to make pages unaware of the existence of other pages, and a process that crashes does not involve other processes.
What processes does the browser have?
This problem becomes clear when you open task Manager. Plug-in has plug-in process, download record has download record process, history record has history record process, GPU process is responsible for 3D rendering and hardware acceleration, routing, TAB page has rendering process……
What if there were no multiple processes?
Imagine that your p-site shares memory data with a social platform. Or B station a collapse, P station also follow collapse, browser a look, also follow collapse.
To keep the browser data secure, the browser robust, and more responsive at run time. The multi-process architecture of the browser was born.
Security: No resources are shared between processes, reducing the possibility of maliciously modifying data of other processes.
Robustness: Crashes of one process are not associated with other processes.
Response speed: Processes can cooperate with each other as quickly as a single process with multiple threads.
Multi-threaded collaboration
What is a render process
The browser rendering process was mentioned above, so why mention it?
- Because this process has more intersection with the front end
- This concept is easy and (renderthreadMixed)
- The rendering process is the Chromium kernel, which can also be called the rendering engine
Output image results through page content/information, CSS, calculation and combination.
What is a thread?
Threads are the minimum unit of CPU scheduling. That means the CPU operates on this thing.
What are the threads in the render process?
Render thread /GUI render thread:
This thread is responsible for the work on the browser Render path, such as token HTML, building the DOM tree, generating the CSSOM tree, composing the Render tree, layout, and drawing.
One thing to note here is that the CSSOM build itself is parallel to the DOM build. If the JS Core thread interrupts the DOM build, then CSSOM will also interrupt the JS Core thread to build CSSOM first.
JavaScript engine threads /JS Core/V8:
As you can see, there are many names, but in fact, they are all the same thing, responsible for parsing and executing JS scripts. JavaScript is single-threaded, but why should it be? Suppose two threads of JS are doing different things to a DOM element at the same time. Of course you can, but introducing the concept of locks is a bit of a waste. So there’s no need to multithread.
This begs the question, why are GUI threads and JS Core threads mutually exclusive?
Since JS has the potential to manipulate the DOM, if run in parallel, it may render an error page, so the GUI will be stored in the queue while THE JS Core is running and will be executed as soon as the JS Core is free.
Event-triggered threads:
It’s what you register for. Since JavaScript is single-threaded, the event is triggered and the callbacks are queued for execution by a JavaScript thread. Not only the event, but also the timer callbacks mentioned later, and asynchronous HTTP request callbacks are placed on this queue. That’s why there’s this thing called event loops.
Timer triggers thread:
This is the same thread as the setInterval and setTimeout, and the callback is queued by the JavaScript thread. Because Js is single-threaded, blocking affects timing accuracy.
Asynchronous HTTP request threads:
A new thread is created after the connection, and when the state changes, the requested callback is queued up for execution by the JavaScript thread.
These threads are called: resident threads. There are many other threads, such as IO threads that communicate with other processes, worker threads, and so on.
What are the advantages of multi-threaded collaboration?
- Multiple threads share memory and process-level resources.
- Thread switching is faster than process switching.
- Multiple threads exchange and cooperate with each other
conclusion
The thread collaboration in the rendering process, i.e. the browser rendering path, will not be discussed in this article, but a new article will be published later. Please follow me if you are interested.
See here please point a like, please!!
I’m Lew, who loves to tell you stories.