How web browsers use Processes and Threads

What are process & Thread?

A process is the execution of a program that allows you to perform the appropriate actions specified in a program. It can be defined as an execution unit where a program runs. The OS helps you to create, schedule, and terminates the processes which is used by CPU. The other processes created by the main process are called child process.

Thread is an execution unit that is part of a process. A process can have multiple threads, all executing at the same time. It is a unit of execution in concurrent programming. A thread is lightweight and can be managed independently by a scheduler. It helps you to improve the application performance using parallelism.

Multiple threads share information like data, code, files, etc. We can implement threads in three different ways:

Kernel-level threads

User-level threads

Hybrid threads

Browser Architecture

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.

Chrome’s recent architecture is described in the diagram below.

The following table describes each Chrome process and what it controls:

Browser-Controls “chrome” part of the application 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 & firefox 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 (a.k.a. “UI” thread in the browser process) and IO thread (each process’ thread for handling IPC) 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.

Every Chrome process has

· a main thread

· an IO thread

· a few more special-purpose threads

· and a pool of general-purpose threads

Years ago, Mozilla made a fateful decision about the future of Firefox development, one that made it much more difficult to integrate multiprocessing into the existing browser. Roughly 10 years ago, the major way Firefox had distinguished itself compared with Internet Explorer was through its support for add-ons and extensions. But the same add-on abilities that had made the browser popular also made it difficult to add multiprocessor support. Mozilla therefore committed to transitioning away from its old add-on model and towards multi-browser web extension support, while simultaneously launching the Electrolysis project to create a new browser version that could support a multi-processing architecture. 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.

Chrome vs Firefox

Chrome and Firefox now both support multithreading, 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.Firefox first 4 tabs each use those 4 processes and additional tabs run using threads within those processes. Multiple tabs within a process share the browser engine that already exists in memory, instead of each creating their own.

however, it is important to note that, chrome is less likely to crash since if one tab(process) crashes, it won’t crash the entire browser. opposite is true in case of firefox.