How web browsers use Processes and Threads
Contrast of Chrome and Firefox browser’s Process and Thread usage.
To understand the rest of the article we need to have a basic understanding of what is a process and a thread.
Process
An instance of a program being executed. It allocates hardware resources and memory to complete the task. Switching between processes requires time. The more processes the more processor usage.
Thread
A small sequence of programmed instruction of a process that can be managed independently by a scheduler. On a modern computer many threads of a single process can run asynchronously. Switching between threads is way more efficient than that of processes.
Chrome and Firefox are the web browsers that majority of people use to crawl into the web. Even you may browsing through this article using one of them right now.
Have you ever wondered how these browsers provide these multiple functionalities. From one tab to another each works like a separate browser. I will illustrate how this amazing piece of software put all together to browse from one tab independently, regardless of other tabs that you have opened.
All these multitasking is achieved through the use of processes and threads.
We will discus the following,
>>> Chrome’s architecture of using processes and threads.
>>> Firefox’s architecture of using processes and threads.
>>> Comparison of functionalities gained from these architectures.
Chrome’s architecture of using processes and threads
Chrome use a separate process for each opened tab.
Also these separate processes are secured by the main controlling engine, also known as the rendering engine. That means it provides restricted access from one process to another. By following this kind of design model these tabs brought more control to the operating system.
The main process in Chrome runs the user interface and manages tab and plugin processes. It is called the browser.
The processes opened as tabs are called the render processes. Each tab processes use some kind of mechanism to bring on their functionalities. As an example it uses Blink open-source layout engine for interpreting and laying out HTML.
The browser process and the render processes communicate using Chromium’s IPC system.
Now lets turn our heads to threading model of each Chrome process.
Every Chrome process has notifiable important two threads:
- A main thread
- An IO thread
In the browser(main) process these two threads are:
- The main thread :- Browser Thread: updates the UI
- The IO thread :- Browser Thread: handles IPCs and network requests
In render processes
- The main thread :- Blink main thread: runs most of Blink
- The IO thread :- handles IPCs to the render engine
Other than to these two threads there are
- Few more special-purpose threads.
- Pool of general-purpose threads in each Chrome process.
Firefox’s architecture of using processes and threads
Firefox also uses multiple process and thread architecture nowadays; but in a whole different manner than chrome.
Few years back Firefox didn’t use a multi-process architecture. What brought back Firefox in the game is the Electrolysis project. It uses the multi-process architecture.
Here is how it work>>>
Firefox creates up to 4 separate processes for web page content. The first 4 tabs each use those 4 processes. Any additional tabs we create run using separate threads within one of those 4 processes.
Comparison of functionalities gained from these architectures.
Since chrome uses one process per one tab the advantage is that when a single tab crash the whole browser doesn’t gets shot down by the kernel. Operating system take control over that crash and we can safely keep our other tabs and data safely. This prevent a complete catastrophe when something goes wrong.
Chrome uses one process for one tab approach this is good on the aspect of a control structure. But when there is so many tabs the memory consumption is too high. Firefox only uses 4 processes and additional tabs are maintained by separate threads. Since multi-threading is faster, Firefox is faster (due to shared memory, context switching is faster in threads).
Resources :-
