How Chrome browser use process & Threads

A “process” is what we call a program that has been loaded into memory along with all the resources it needs to operate. A “thread” is the unit of execution within a process. A process can have anywhere from just one thread to many threads.

Multiprocessing is the use of two or more central processing units within a single computer system. The term also refers to the ability of a system to support more than one processor or the ability to allocate tasks between them.

Multithreading is a type of execution model that allows multiple threads to exist within the context of a process such that they execute independently but share their process resources.

Chrome has a multi-process architecture and each process is heavily multi-threaded. 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.

Every Chrome has main threads and IO threads.

Main threads:

· In the browser process (Updates the UI)

· In render processes (runs most of the Blink)

IO threads:

· In the browser process (handles IPCs and network requests)

· In renderer processes (handles IPCs)

Most threads have a loop that gets tasks from a queue and runs them.

Examples of different type of processes created by Chrome:

· Browser:

Tabs, windows, and “chrome” of the browser manage this browser process. This process also handles all interactions with the disk, network, user input, and display. And it makes no attempt to parse or render any content from the web.

· Renderers:

The render processes contain all the complex logic for handling HTML, JavaScript, CSS, and so on. It created by the browser process. It is responsible for each rendering web pages. All interactions with apps, including user input events and screen painting, must go through the browser process. This allows 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.

USE PROCESS

Chrome uses multiple render process. Each render process has a global RenderProcess object. It manages communication with the parent browser process and maintains a global state. The browser maintains a corresponding RenderProcessHost for each render process, which manages browser state and communication for the renderer. Chromium’s IPC system provides a communication facility for the browser and the renderers.

In the render process,

The RenderProcess handles IPC with the corresponding RenderProcessHost in the browser. There is exactly one RenderProcess object per render process.

The RenderView object communicates with its corresponding RenderViewHost in the browser process and our WebKit embedding layer. This object represents the content of one web page in a tab or popup window.

In the Browser process,

There is a top-level browser window represented by the browser object.

The connection between a single browser and renderer IPC represented by the RenderProcessHost object. There is using one RenderProcessHost.

In general, each new window or tab opens in a new process. The browser will spawn a new process and instruct it to create a single RenderView. A web application opens a new window that it expects to communicate with synchronously.

When we are working with multiple tabs within a chrome browser, each tab is run by an independent renderer process (use multi-process). If one tab becomes unresponsive, then we can close the unresponsive tab and remove on while keeping other tabs alive.

The browser’s work into multiple processes is security and sandboxing. Since operating systems provide a way to restrict processes’ privileges, the browser can sandbox certain processes from certain features.

USE THREADS

A thread is the unit of execution within a process. A process can have anywhere from just one thread to many threads. In multithreaded processes, the process contains more than one thread and the process in accomplishing a number of things at the same time.

The threading model is, at its implemented level, quite complex. Keeping it simple, what basically happens is that there is one main process handling user interactions, the browser, operating system calls, and persistent data. That being the “browser” process. This browser process contains several threads, each with different responsivities, but the only one we need to focus on at this level is the I/O thread.

The chrome browser tries to bridge the gap between common threading nomenclature. Using the following terms,

· Thread-unsafe

This is the vast majority of type in Chrome. Access to such types/methods must be externally synchronized.

· Thread-affine

Such types/methods need to be always accessed from the same physical thread and typically have a THREAD_CHECKER member to verify that they are.

· Thread-safe

Such types/methods can be safely accessed concurrently.

· Thread-compatible

Such types provide safe concurrent access to const methods but require synchronization for non-const.

· Immutable

A subset of thread-compatible types which cannot be modified after construction.

· Sequence-friendly

Such types/methods are thread-unsafe types that support being invoked from a SequencedTaskRunner.