How Web Browsers use Processes and Threads

Process And Threads

Process means any program is in execution. Process control block controls the operation of any process. Process control block contains the information about processes for example: Process priority, process id, process state, CPU, register etc. A process can creates other processes which are known as Child Processes. Process takes more time to terminate and it is isolated means it does not share memory with any other process.

Thread is the segment of a process means a process can have multiple threads and these multiple threads are contained within a process. Threads share the address space of the process that created it. A thread have 3 states: running, ready, and blocked. Thread takes less time to terminate as compared to process and like process threads do not isolate. processes have their own copy of the data segment of the parent process and Threads have direct access to the data segment of its process. Both Process and threads used to achieve concurrency in web browsers.

Process and Threads in Chrome

By default, Chrome creates a process for each tab of a web site the user visits and plugins extensions it uses. This ensures that pages from different sites are rendered independently, and that separate visits to the same site are also isolated from each other. Thus, failures (e.g., site crashes) or heavy resource usage in one instance of a site will not affect the rest of the browser. There is also processes for main browser and GPU functionality.

Google Chrome creates three different types of processes: browser, renderers, and plug-ins.

Browser :- There’s only one browser process, which manages the tabs, windows, and “chrome” of the browser. This process also handles all interactions with the disk, network, user input, and display, but it makes no attempt to parse or render any content from the web.

Renderers :- The browser process creates many renderer processes, each responsible for rendering web pages. The renderer processes contain all the complex logic for handling HTML, JavaScript, CSS, images, and so on. Each renderer process is run in a sandbox, which means it has almost no direct access to your disk, network, or display. All interactions with web apps, including user input events and screen painting, must go through the browser process. This lets the browser process monitor the renderers for suspicious activity, killing them if it suspects an exploit has occurred.

Plug-ins :- The browser process also creates one process for each type of plug-in that is in use, such as Flash, Quicktime, or Adobe Reader. These processes just contain the plug-ins themselves, along with some glue code to let them interact with the browser and renderers.

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

The advantage of the multiprocess approach is that websites run in isolation from one another. If one website crashes, only its renderer process is affected. all other processes remain unharmed. Furthermore, renderer processes run in a sandbox, which means that access to disk and network I/O is restricted, minimizing the effects of any security exploits.

Process and Threads Firefox

Historically, Firefox has been a single-process browser. As it turned out, running the browser UI plus the HTML rendering and JavaScript for all tabs in a single process is a bad idea. It easily freezes the UI, and it might not be optimal from a security point of view, either.

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.

Mozilla started project Electrolysis as a gradual move to a multi-process architecture.

The Current architecture of Firefox has a main process, one GPU process, one extension process, up to 4 tab processes.

Chrome vs Firefox

While both Firefox and Chrome now run using multiple processes, Firefox does some things differently to avoid using up user computer’s limited memory.

By default, Chrome creates a separate content process for each instance of a site that you visit. Open 10 different tabs with 10 sites in Chrome, and it will have 10 different processes. Each of those processes has its own memory — with their own instance of the browser’s engine. One open tab in Chrome typically consumes hundreds of megabytes of RAM. Chrome’s liberal approach to creating processes can lead to very high memory usage.

On the other hand, Firefox’s more conservative approach to using processes often results in Firefox using less memory than Chrome. By default, Firefox now creates up to 4 separate processes for web page content. So, your 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.