Process Model for Chrome source code analysis (8)

In Chrome's multi-process model, there is a master process and multiple auxiliary processes. The main process browser is responsible for processing most of Chrome's work, and is responsible for creating and destroying other auxiliary processes. The auxiliary processes are called Renderer processes, which are mainly responsible for page display. Each Renderer process corresponds to one or more pages or sites. The following is a process model diagram on the chrome homepage. The multi-process model of Chrome is vividly displayed.

Generally, Windows applications work in the form of a single process. Why does chrome adopt the multi-process mode. The official documents clearly explain that Google believes that today's browsers are a bit similar to the early single-user multitasking operating system, an exception caused by a plug-in can cause the entire browser and the web pages opened by the plug-in to crash. Therefore, Google decided to run different pages in different processes, so that exceptions on a page will only cause the page to crash, but will not affect the work of other pages and the entire browser.

Through this figure, we can clearly see that the browser process includes multiple threads, at least one mainthread and one I/O thread.

The code for creating the main thread is as follows:

Void browsermainparts: mainmessageloopstart (){
Premainmessageloopstart ();

Main_message_loop _. Reset (New messageloop (messageloop: type_ui ));

// Todo (viettrungluu): shocould these really go before setting the thread name?
System_monitor _. Reset (New systemmonitor );
Hi_res_timer_manager _. Reset (New highresolutiontimermanager );
Network_change_notifier _. Reset (net: networkchangenotifier: Create ());

Initializemainthread ();

Postmainmessageloopstart ();
}

Analyze this code. First, create a messageloop object. In the constructor, messageloop will keep the pointer to itself in the TLS of the current thread, as follows:

Lazy_tls_ptr.pointer ()-> set (this );

This will be used in many places in the future. For example, when callback functions of many Io threads call, this pointer will be obtained to determine whether they are running on the IO thread. If not, an exception will be triggered, the constructor also sets the thread type value.

The next step is to initialize the system monitoring object and the network_change_notifier _ object.

Start mainthread initialization. Here main_thread _ is called _. reset (New browserthread (browserthread: Ui, messageloop: Current (), creates an object corresponding to the current thread, and all the work ends here, the message loop of the main thread starts only after the main window is created. runuimessageloop (browser_process.get () is called ());

At the same time, a rendererprocesshost object is created in browserprocess. Each rendererprocesshost corresponds to an rendererprocess. rendererprocess also contains multiple rendererviewhost objects. Each rendererviewhost corresponds to an rendererprocess renderview object, renderview corresponds to the page label visible to this user. Rendererprocess is mainly responsible for displaying HTML pages using the Web rendering engine. Currently, Google uses the WebKit and V8 Dual Engines to render pages. Starting from 28, rendererprocess will be replaced by the blink engine. As you can see, a rendererprocess manages rendering of multiple pages at the same time. Rendererprocess itself does not have the network communication function. If the rendererprocess engine needs data, it must be obtained from browserprocess through inter-process communication. The rendererprocesshost in the main process is used to establish a connection with the same identified rendererprocess. Each rendererprocesshost establishes a fixed connection with rendererprocess through a channel, which is maintained until rendererprocess is destroyed. The channel uses the named Pipeline mechanism at the underlying layer. Later, we will analyze the inter-process communication mechanism.

Browserprocess also has an IO thread. Responsible for all network communication and inter-process communication. Data requests generated by each rendererprocess are sent to the IO process after the master process is sorted. The IO process contains a resourcedispatcherhost. The Network request is processed by resourcedispatcherhost and then sent to the Web server through the underlying network interface.

The official design documentation is here: http://dev.chromium.org/developers/design-documents/multi-process-architecture