Chrome Kernel parsing-background: Multi-process multithreaded architecture for chromium

Reprint Please specify source: http://blog.csdn.net/yunchao_he/article/details/41695497

Chromium uses a multi-process architecture, in the case of desktop chromium, which includes a browser process (also known as UI process), one or more render processes (also known as Web process), 0 or one GPU process, and one or more NPAPI Plugin process, one or more pepper Plugin process.

That is, when you use Chrome browser to open multiple sites (such as Open NetEase, Renren, BBS, Taobao), and each site may correspond to multiple tab (such as NetEase opened a headline, a financial news, a sports news, and Taobao opened a number of shopping window to buy clothes, thus contrast), At this point the system corresponds to a browser process, and (by default) multiple render processes, possibly a GPU process, and an unequal number of plugin processes. This can be viewed through the appropriate tools, such as the Task Manager under Windows.

Each process may contain multiple threads, such as the browser process including the main thread, the compositor thread, the I/O thread, one or more resource download threads, the file manipulation thread, and many more. The main thread is responsible for initiating the network request, calling the render process to start parsing the HTML and executing JS, receiving and responding to user actions (such as dragging scrollbars), and so on. The compositor thread is responsible for compositing the Web page content and the browser's widgets to form the final pixel to be displayed.

The render process includes the main thread, compositor threads, raster threads, and so on. The main thread is responsible for executing JavaScript, parsing html/css, completing drawing or initiating raster thread to draw, initiating compositor thread, etc. The compositor thread is responsible for compositing each layer of the Web page. The raster thread is responsible for completing a layer or some block (tile) drawing.

The benefits of a multi-process architecture are obvious, with each process and thread working together to take advantage of multicore features to improve operational efficiency or responsiveness. On the other hand, process separation minimizes the crash of a Web site by preventing it from crashing as a result of access. This way, the user edits on other sites and uncommitted files or other operations are not lost.

In addition, how much of the render process can be configured when you start chrome, the relevant command line parameters are--process-per-site-instance,--process-per-site,--process-per-tab,-- Single-process and so on. With these parameters, you can allow multiple tabs of the same domain name to share the same render process (as mentioned above to open NetEase's many news, or multiple Taobao shopping window), or each tab will occupy a single render process, or all domain names share a render process.

Inter-process using chromium IPC communication mechanism, specifically can refer to http://www.chromium.org/developers/design-documents/inter-process-communication. For Chrome's multi-process architecture, refer to Http://www.chromium.org/developers/design-documents/multi-process-architecture. And how to set the shared behavior of the render process through command line parameters, refer to Http://www.chromium.org/developers/design-documents/process-models