CEF3 Developer series of processes and threads

CEF3 is a multi-process architecture framework, and if you have an understanding of the chromium process architecture, it is easy to understand the multi-process of CEF3. Open the Cefclient instance published in the CEF3 source code if the open page has flash or another plugin. In task management, you can see four processes that show the command line. You can see a main process, the main process is the browser process, the other is the rendering process (render), GPU acceleration process (GPU), plug-in process (NPAPI or PPAPI).

Browser process: is defined as the main process, responsible for window management, interface drawing and network interaction.

Render process: Blink rendering and JS execution are placed in a separate render process; In addition, the render process is responsible for JS binding and access to the DOM node. In the default process model, a new render process is created for each tab page.

NPAPI Plugin process: Create on demand, each type of plug-in will only have one process, each plug-in process can be shared by multiple render processes;

Pepper plug-in process: With the NPAPI plug-in process, the difference is the process created for the pepper plugin;

GPU Process: Created on demand, at most, only when GPU hardware acceleration is turned on and is used primarily for implementations of 3D accelerated calls.

Many benefits of multi-process, the main advantage in the browser is when a page or plug-in crashes or suspended animation, will not affect other pages. CEF3 processes can be communicated through the IPC. The browser and render processes can communicate in two directions by sending asynchronous messages. Even the render process can register the asynchronous JavaScript API in response to the browser process. In CEF3, the browser and render processes can be passed through Sendprocessmessage (Cefprocessid target_process, cefrefptr<cefprocessmessage> Message) function for messaging.

By default, the main application is started multiple times to run its own separate processes. Implemented by passing different command-line arguments to the cefexecuteprocess function. If the main application is large, the load time is longer, or it cannot be used in a non-browser process, the host program can run these processes using a standalone executable file. This can be done by configuring the Cefsettings.browser_subprocess_path variable. More

The chromium itself supports a variety of process models, but the CEF3 is primarily a model: single-process and create a process for each label. The latter is the default behavior, the front one can be set. The single-process run model for debugging purposes can be supported by setting the--SINGLE-PROCESS,CEF3 of the command line. Supported platforms are: Windows,mac OS X and Linux.

A graphical representation of the process model of the default Chromium browser. The box represents the process, and the connection line represents the IPC interprocess communication.

Since there is little explanation about the architecture of the CEF3 process, the individual guesses that the CEF3 process architecture and chromium should be similar, after all CEF3 is based on the chromium framework. More process-related content can be searched online for "Chromium multi-process architecture".

In CEF3, each process will run multiple threads. For a complete thread type table, refer to cef_thread_id_t

typedef enum {//BROWSER process THREADS-only available in the BROWSER process.  //The main thread in the browser. This would be the same as the main  //application thread if Cefinitialize () are called with a  //cefsettings.multi_t Hreaded_message_loop value of FALSE.  tid_ui,   //used to interact with the database.  tid_db,////used to interact with the  file system.  Tid_file,  //used for the FILE system operations that block user interactions.  Responsiveness of this thread affects users.  Tid_file_user_blocking,  ///  /used to launch and terminate browser processes.  Tid_process_launcher,  //used to handle slow HTTP cache operations.  Tid_cache,  //used to process IPC and network messages.  tid_io,//Render Process THREADS-only available in the render process.  //The main thread in the renderer. Used for all WebKit and V8 interaction.  Tid_renderer,} cef_thread_id_t;

The following major threads are included in the browser process:

• TID_UI threads are the main thread of the browser. If the application passes the Cefsettings.multi_threaded_message_loop=false when calling Cefinitialize (), this thread is also the main process of the application.
• The TID_IO thread is primarily responsible for processing IPC messages and network traffic.
• The tid_file thread is responsible for interacting with the file system.

Because CEF employs a multithreaded architecture, it is necessary to use locks and closures to ensure thread-safe semantics of data. The implement_locking definition provides the lock () and Unlock () methods as well as autolock objects to ensure that different blocks of code access data synchronously. The Cefposttask function group supports easy asynchronous message passing between threads. For more information, please refer to the Posting Tasks section.

The current thread environment can be judged by the Cefcurrentlyon () method, and the Cefclient project uses the following definition to ensure that the method is executed in the desired thread.

#define Require_ui_thread () ASSERT (Cefcurrentlyon (tid_ui));
#define Require_io_thread () ASSERT (Cefcurrentlyon (tid_io));
#define Require_file_thread () ASSERT (Cefcurrentlyon (tid_file));

CEF3 Developer series of processes and threads