Chormium threading Model and Application guide

Core Concepts

The following principles are adhered to in design:

1 do not do any blocking I/O operations on the UI thread, and other time-consuming operations, passing the various operations to the appropriate thread through messaging.

2 line loads lock mechanism and thread-safe objects are discouraged. The object has only one thread, which communicates between threads through messages, and threads do not block each other. Cross-thread requests are implemented through callback objects.

In general, we should take advantage of an existing thread and try not to create a new thread. The UI thread is actually set to disallow I/O operations and is not allowed to wait.

Thread List

List of core threads

owning Process	Thread Name	type	Responsibilities	Implement
Browser	Ui/browserthread	Java	The main thread of the browser	Content::browserthreadimpl
Browser	Chrome_dbthread	Native	Responsible for database (SQLite) related operations, many of the implementation of the function will be used to this thread.	Content::browserthreadimpl
Browser	Chrome_filethread	Native	File creation, deletion, read-write, and so on.	Content::browserthreadimpl
Browser	Chrome_fileuserblockingthread	Native	For reading data related to user interaction, a quick response is required. It is useful to see the net Log module and AppCache.	Content::browserthreadimpl
Browser	Chrome_processlauncherthread	Native	Used to start and terminate child processes.	Content::browserthreadimpl
Browser	Chrome_cachethread	Native
				Content::browserthreadimpl
Browser	IndexedDB	Native	Indexdb the storage thread.	Base::thread
Gpu	Chrome_inprocgputhread	Native	Single-process version implementation of the GPU.	Content::inprocessgputhread
Child Processes	Chrome_childiothread	Native	The IO thread implementation of the child process.	Base::thread
Renderer	Chrome_inprocrendererthread	Native	The single-process version implementation of the renderer process.	Content::inprocessrendererthread

Other threads

Thread Name	Module	Implement	Description
Cookiemonsterclient	CAW	Base::thread
Cookiemonsterbackend	CAW	Base::thread
Cookiesyncmanager	WebView	Runnable
Chrome_libjingle_workerthread	Browser	Base::thread
Blink Heap Marker Thread (*)	Blink	Base::thread
Blink GC Sweeper (*)	Blink	Base::thread
Htmlparserthread	Blink	Base::thread
Asynctransferthread	Gpu	Gpu::transferthread
Browserblocking Worker	Browser	Base::sequencedworkerpool	See: Key points of application of C + + concurrency technology in chromium
Simplecache Worker	Net	Base::sequencedworkerpool
Network File Thread	Net	Base::thread

Thread structure

(in single-process model description)

Message structure for Android offline thread

thread structure of chromium

Description of responsibilities for each class:

class	Description of responsibilities
runloop	A helper class that mainly encapsulates the message loop Messageloop class, Its
messageloop	The main message loop, in principle, it should be able to handle three types of messages, including messages that support different platforms. In fact, if you let it handle all of these messages, it can make its code structure confusing. There are only three types of message loops: One can only handle custom tasks a way to handle custom tasks and IO operations One is the ability to handle custom tasks and UI messages. Naturally, Chromium defines a base class Messageloop for handling custom tasks, and two subclasses correspond to the second and third types. For the second and third types of messageloop, they handle platform-related messages in addition to handling tasks, and for a clear structure, chromium define a new base class and its subclasses to handle them, which is Messagepump. Each subclass of Messagepump is
messagepump	An abstract base class, Can be used to handle the second and third types of messages listed above. For each platform, they have a different subclass of messagepump, which are included in the Messageloopforui and Messageloopforio classes.

Excerpt from:<< understanding WebKit and Chromium>>

Browser Thread Structure

Browser-side throw thread message, mainly based on the method provided by the Browserthread to complete, as follows:

//detection of the thread dcheck (Browserthread::currentlyon:: UI));   //Toss task to UI thread execution browserthread::P osttask (Browserthread::ui, From_here,           base::bind (&awlogindelegate::handlehttpauthrequestonuithread,                      This , (count->auth_attempts_ = = 0 )));   //Throw task to IO thread browserthread::P osttask (Browserthread::io, From_here,        base::bind (&awlogindelegate::P roceedoniothread,                    This , user, password));

The thread structure of the render end

Renderer end-throw message, mainly based on the messageloopproxy to complete. As follows:

base::Closure closure =        base::Bind(&CompositorOutputSurface::ShortcutSwapAck,                   weak_ptrs_.GetWeakPtr(),                   output_surface_id_,                   base::Passed(&frame->gl_frame_data),                   base::Passed(&frame->software_frame_data));base::MessageLoopProxy::current()->PostTask(FROM_HERE, closure); // input_event_filter.cc中的示例io_loop_->PostTask(FROM_HERE,                     base::Bind(&InputEventFilter::SendMessageOnIOThread,                                this,                                base::Passed(&message))); // Blink platform implemetationbase::MessageLoopProxy::current()->PostTask(      FROM_HERE,      base::Bind(&PlatformEventObserverBase::SendFakeDataForTesting,                 base::Unretained(observer), data));

GPU-to-browser/renderer interaction

Thread Safety

For Java and Android thread safety no longer expanded, you can refer to the attached information: <<efficient Android Threading asynchronous processing techniques for Android Applications>>

Java is recommended for Java concurrent combat.

The most commonly used form, the object to be used is defined as Base::refcountedthreadsafe. Guarantees that the referenced object will not be refactored in advance.

For some non-thread-safe classes, you can use Nonthreadsafe to provide debug mode thread security acknowledgments. You can also apply threadcollisionwarner/threadchecker to ensure that the running thread is consistent with the design.

See: Key points of application of C + + concurrency technology in chromium

Reference: How to safely use the Posttask

cancellation of the task

In addition to canceling a task as needed, it can cause a crash if executed after the host class is destructor. There are two ways to ensure the cancellation of a task:

Weakptrfactory (weakptr) and Cancelabletasktracker, they also automatically cancel the task when they are refactored.

Cancelabletasktracker can refer to the Chromium official website's instructions or the application in Faviconcache.

class UserInputHandler : public base::RefCountedThreadSafe<UserInputHandler> {  // Runs on UI thread.  void OnUserInput(Input input) {    CancelPreviousTask();    DBResult* result = new DBResult();    task_id_ = tracker_->PostTaskAndReply(        BrowserThread::GetMessageLoopProxyForThread(BrowserThread::DB).get(),        FROM_HERE,        base::Bind(&LookupHistoryOnDBThread, this, input, result),        base::Bind(&ShowHistoryOnUIThread, this, base::Owned(result)));  }  void CancelPreviousTask() {    tracker_->TryCancel(task_id_);  }  ... private:  CancelableTaskTracker tracker_;  // Cancels all pending tasks while destruction.  CancelableTaskTracker::TaskId task_id_;  ...};

For Weakptr,chromium, a weakptrfactory is already encapsulated for use. You can refer to the use in Gpubrowsercompositoroutputsurface. The use of the method is relatively simple, but not cancelabletasktracker universal.

The following is a simple example (the greatest benefit of using weakptrfactory<> is that you do not have to modify the definition of the class.)

class MyObject { public:  MyObject() : weak_factory_(this) {}  void DoSomething() {    const int kDelayMS = 100;    MessageLoop::current()->PostDelayedTask(FROM_HERE,        base::Bind(&MyObject::DoSomethingLater, weak_factory_.GetWeakPtr()),        kDelayMS);  }  void DoSomethingLater() {    ...  } private:  base::WeakPtrFactory<MyObject> weak_factory_;};

* Non-thread-safe, can be passed across threads, but must be used on one thread, that is, this mechanism can only be used on tasks running on the same thread. Weakptr

* Members of the weakptrfactory<foo> Weak_factory_ in the class need to be placed behind all other members to ensure that weakptrs is not valid when the other member's destructor is executed.

further explanations of weakptr can be found in:The weak_ptr in chromium, as wellOn the choice of Supportweakptr and Weakptrfactory.

Chormium threading Model and Application guide