webkit2 process model
Webkit2 High Level View
Notice that there is now a process boundary, and it sits *below* the API boundary. Part of WebKit operates in the UI process, where the application logic also lives. The rest of WebKit, along with WebCore and the JS engine, lives in the web process. The web process is isolated from the UI process. This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multi-core CPUs. There is a straightforward API that takes care of all the process management details for you.
There are 2 process models in WebKit (more precisely, there are 3, but for now I don’t take with thread-based solutions into account): the default is the secondary process model, and we can easily switch to shared process model as well.
Shared Secondary process model is default process model in webkit2.
Use a single process to perform content rendering. The process is shared among all the WebKit2 WebView instances created by the application: if the process hangs or crashes all the web views in the application will be affected. This is the default process model, and it should suffice for most cases.
Another Process model: Secondary Process Model
This process model use one process for each WebKit2 WebView, while still allowing for some of them to share a process in certain situations. The main advantage of this process model is that the rendering process for a web view can crash while the rest of the views keep working normally. This process model is indicated for applications which may use a number of web views and the content of in each must not interfere with the rest — for example a full-fledged web browser with support for multiple tabs.