How web browsers use Processes and Threads
The web browsers could be one process with many different threads or many different processes with a few threads communicating over IPC.
The important thing to note here is that these different architectures are implementation details. There is no standard specification on how one might build a web browser. One browser’s approach may be completely different from another.
At the top is the browser process coordinating with other processes that take care of different parts of the application. For the renderer process, multiple processes are created and assigned to each tab. Until very recently, Chrome gave each tab a process when it could; now it tries to give each site its own process, including iframes.
What is the browser process?
The Browser process is also known as the browser for short (this is not the same idea as the Browser we generally speak of, which refers to a program on your computer that allows interacting with information from the internet). This process is mainly responsible for managing all render processes and displaying UI.
What is the Renderer process?
Renderer processes contain logic for rendering web pages. Thus, they contain the logic for handling HTML, Javascript, images, and so forth. As a general rule, a new renderer process is created for each website opened in a new tab, and so several renderer processes may be active at the same time.
What are the multiple processes?
A plug-in process is created for each type of plug-in (such as Flash or QuickTime) in use. Plug-in processes contain the code for the plug-in as well as additional code that enables the plug-in to communicate with associated renderer processes and the browser process.
How to google chrome use Processes and Threads
Chrome has a multi-process architecture and each process is heavily multi-threaded. The main goal is to keep the main thread (“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.
Threads
Every chrome process has,
- a main thread
In the browser process (BrowserThread::UI): updates the UI and In renderer processes (Blink main thread): runs most of Blink
2. an IO threads
in the browser process (BrowserThread:: IO): handles IPCs and network requests.
In renderer processes: handles IPCs. A few more special-purpose threads and a pool of general-purpose threads.
How Firefox use Processes and Threads
chrome uses multiprocessing and firefox uses multithreading. so each tab in chrome is a process whereas in firefox each tab is a thread. since multithreading is faster, firefox is faster(due to shared memory, context switching is faster in threads).
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. the opposite is true in the case of firefox.
Google has released its own open-source browser, Chrome, in direct competition to Firefox and Microsoft Internet Explorer. Yesterday, Danny described his test-drive of Chrome in Searching With Google Chrome & Omnibox and Greg speculated on its future in How Bright Is The Outlook For Chrome?. Both compared Google’s new browser to the incumbents, Firefox, and Internet Explorer. But Chrome is actually very different from those two browsers, and significantly different from nearly everything else on the market. Here are the 10 major features that truly differentiate Google Chrome from the competition.
Chrom uses concepts of process. Each tab in firefox acts as a process. And thus ’n’ number of tabs will spawn n number of processes in chrome. Firefox uses threads, which means context switching is faster.
Comparing Chrome and 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 battery life. Firefox doesn’t take this approach to the problem but instead spins up to four content process threads by default. In Firefox, the 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.
