How web browsers use process & Threads ?( Firefox VS Chrome)

Another concept to grasp before diving into browser architecture is Process and Thread. A process can be described as an application’s executing program. A thread is the one that lives inside of process and executes any part of its process’s program. When you start an application, a process is created. The program might create thread(s) to help it do work, but that’s optional.

So how is a web browser built using processes and threads? Well, it could be one process with many different threads or many different processes with a few threads communicating over IPC. There for browser architecture is mainly based on process and threads.

Threads are living in a process, along with data, codes, and files. In a single-threaded process, well, there is only one thread. It is also the main thread of the process. A thread is a queue, processing tasks one by one. The next task has to wait until the earlier ones finish. In a multi-threaded process, the tasks can process faster in multiple threads simultaneously. All threads share the data in the memory. If one of the threads stops, the process is terminated and exists.

Before modern browsers exist, we used the single-process browser. IE6 was the most popular one.This architecture brings three problems: instability, low performance, and insecurity. After that introduced ,multi process browser, well, we have multiple processes. Between processes, they communicate with Inter-process communication (IPC). Each process runs various threads.

Nowadays, we have the following processes running in a browser,
* Browser process
* Render process
* Plugin process
* GPU process
*Network process
*Device process
*Video process (one of the utility processes)
*Audio process (one of the utility processes)

Which process controls what?

Browser :- Controls the applications including address bar, bookmarks, back and forward buttons. Also handles the invisible, privileged parts of a web browser such as network requests and file access.

Renderer :- Controls anything inside of the tab where a website is displayed.

Plugin :- Controls any plugins used by the website, for example, flash.

GPU :- Handles GPU tasks in isolation from other processes. it is separated into different process because GPUs handles requests from multiple apps and draw them in the same surface.

How Google Chrome Use Processes and Threads

Chrome has a multi process architecture and each process is heavily multi-threaded. In this document we will go over the basic threading system shared by each process. The main goal is to keep the main thread and IO thread responsive. This means offloading any blocking I/O or other expensive operations to other threads. Our approach is to use message passing as the way of communicating between threads. We discourage locking and thread-safe objects. Instead, objects live on only one thread and we pass messages between those threads for communication.

And also every process has thread like this.first one is a

main thread,

• in the browser process (BrowserThread-UI) updates the UI
• in renderer processes (Blink main thread) runs most of Blinkin

An IO thread,

• in the browser process (BrowserThread-IO) handles IPCs and network requests
• in renderer processes: handles IPCs

And also have special-purpose threads and pool of general-purpose threads

The benefit of multi-process architecture in Chrome

In the most simple case, you can imagine each tab has its own renderer process. Let’s say you have 3 tabs open and each tab is run by an independent renderer process. If one tab becomes unresponsive, then you can close the unresponsive tab and move on while keeping other tabs alive. If all tabs are running on one process, when one tab becomes unresponsive, all the tabs are unresponsive.Another benefit of separating the browser’s work into multiple processes is security and sandboxing.

How Firefox Use Processes and Threads

In older versions of Firefox for desktop, the entire browser ran within a single operating system process. Specifically, the JavaScript that ran the browser UI (also known as “chrome code”) and the JavaScript that ran within web pages (also known as “content” or “web content”) were not separated.

Currently, the latest versions of Firefox run the browser UI and the web content in separate processes. In the current iteration of this architecture, all browser tabs run within the same process and the browser UI runs in its own individual process. In future iterations of Firefox, there will be more than one process to exclusively handle web content. The internal name for this project is called Electrolysis, sometimes abbreviated to e10s.

The good news is that normal web pages and their developers are unaffected by this changeover to a multi process -based Firefox. Unfortunately, people developing for Firefox or Firefox add- ons will be affected if their code relies on being able to access web content directly since the system for accessing this data is going to change.

Instead of accessing web content directly, chrome code will have to use the message manager instead. To help ease this transition we’ve implemented Cross process object wrappers and some compatibility shims for add-on developers. If you are an add-on developer wondering whether or not you are affected by this change, see the guide to working with multi process Firefox.

What is the Different of Chrome and Firefox

Chrome and Firefox now both support multi threading, but they do it in different ways. In Chrome, each and every tab you open gets its own content process. Ten tabs, 10 processes. One hundred tabs, 100 processes. This approach maximizes performance, but you pay a hefty penalty in memory consumption and (when applicable) battery life. Firefox doesn’t take this approach to the problem, but instead spins up to four content process threads by default.

Mozilla claims that Firefox also uses dramatically less memory than other competing browsers, with Chrome using 1.77x more RAM than Firefox in 64-bit and 2.44x in 32-bit mode. The differences were less dramatic in Mac OS X and Linux (1.36x and 1.42x, respectively). According to the team, Firefox leads in every category. RAM usage isn’t a battery life issue-memory consumes about the same amount of power whether you are storing data in it or not, provided that you aren’t running some kind of page-hammering benchmark. But having more RAM available does mean a better, smoother experience when juggling a lot of open tabs while running other programs. Finally , Firefox will utilize threads to focus computing power and your network connection on the tabs you’re actively using. Firefox will get much faster, while still being respectful of your memory and your needs.