Process and thread model for Chrome source code analysis (3)

About chrome thread model, there is a special introduction in his development documentation, the original address here: http://dev.chromium.org/developers/design-documents/threading

Chrome processes, Chrome does not use a single-process multi-thread model of a general application, but uses a multi-process model, according to his text description, A tab in the main interface framework corresponds to this process. But in fact, a process not only contains a page, but actually similar pages share a process.

There are two processes in the chrome Process Model: one is the browser process. The other is the Renderer process. There is only one browser that controls the operation of the entire system, while the Renderer can have multiple, mainly responsible for page rendering and display.

Browser is the first to start the main process. Browser contains a main thread mainthread, which initializes the entire system and starts as several other threads. See the following code:

Void createchildthreads (browserprocessimpl * process ){
Process-> db_thread ();
Process-> file_thread ();
Process-> process_launcher_thread ();
Process-> cache_thread ();
Process-> io_thread ();
}

The db_thread thread is responsible for database processing, file_thread is responsible for file management, and cache_thread is responsible for managing cache. Io_thread is responsible for managing inter-process communication and all I/O actions.

Io_thread is not only responsible for the I/O of the browser process, but also the I/O requests of other Renderer are sent to this thread through inter-process communication, which is used for processing, finally, the result is returned to each Renderer process. The functions of each thread are different, but the design mode is the same. Next we will focus on the initialization and execution processes of io_thread.

The thread is created in createiothread of browserprocessimpl. The Code is as follows:

Void browserprocessimpl: createiothread (){
Dcheck (! Created_io_thread _ & io_thread _. Get () = NULL );
Created_io_thread _ = true;

Pluginservice: getinstance ();

# If defined (use_x11)
// The lifetime of the background_x11 thread is a subset of the IO thread so
// We start it now.
Scoped_ptr <base: thread> background_x11_thread (
New browserprocesssubthread (browserthread: background_x11 ));
If (! Background_x11_thread-> Start ())
Return;
Background_x11_thread _. Swap (background_x11_thread );
# Endif

Scoped_ptr <iothread> thread (New iothread );
Base: thread: Options options;
Options. message_loop_type = messageloop: type_io;
If (! Thread-> startwitexceptions (options ))
Return;
Io_thread _. Swap (thread );
}

Create an iothread instance, set the thread type to type_io, and then call startwitexceptions to start the thread.

The startwitexceptions function first saves the passed options and then creates a thread through platformthread: Create. Here, the role of the platformthread class is to support the creation of threads on different system platforms. Call startup_data.event.wait () to wait for the thread to start the message loop. This indicates that the entire function can be returned only after the message loop is started.

In platformthread: Create, the system apicreatethread is called. The thread function is threadfunc, and the parameter passed to the thread function is the pointer of the iothread object.

Threadfunc is also very simple, and then calls the threadmain Member of the thread, so threadmain is the main function of the thread.

The following is a detailed analysis of threadmain. First, define a messageloop Class Object and assign the previously saved type to this object. Next, call the init of iothread to perform basic initialization, and then call startup_data _-> event. Signal () to make the thread untrustworthy. Finally, call the run of messageloop to enter an infinite message loop until the command to exit the message loop is received, and the thread ends. This is a common method for Windows threads, but chrome encapsulates it and defines several different message loops.

An enumeration variable in messageloop is defined as follows:

Enum type {
Type_default,
Type_ui,
Type_io
};

It can be seen that there are three different message loops in total.

Messageloopforui: Run (dispatcher * dispatcher );

Void messageloop: runhandler ()