diff options
Diffstat (limited to 'chromium/docs/website/site/developers/design-documents/multi-process-resource-loading/index.md')
| -rw-r--r-- | chromium/docs/website/site/developers/design-documents/multi-process-resource-loading/index.md | 86 |
1 files changed, 0 insertions, 86 deletions
diff --git a/chromium/docs/website/site/developers/design-documents/multi-process-resource-loading/index.md b/chromium/docs/website/site/developers/design-documents/multi-process-resource-loading/index.md deleted file mode 100644 index 1f080e0cd8b..00000000000 --- a/chromium/docs/website/site/developers/design-documents/multi-process-resource-loading/index.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -breadcrumbs: -- - /developers - - For Developers -- - /developers/design-documents - - Design Documents -page_name: multi-process-resource-loading -title: Multi-process Resource Loading ---- - -[TOC] - -## This design doc needs update. Some figures contains stale information. - -## Background - -All network communication is handled by the main browser process. This is done -not only so that the browser process can control each renderer's access to the -network, but also so that we can maintain consistent session state across -processes like cookies and cached data. It is also important because as a -HTTP/1.1 user-agent, the browser as a whole should not open too many connections -per host. - -## Overview - -Our [multi-process](/developers/design-documents/multi-process-architecture) -application can be viewed in three layers. At the lowest layer is the Blink -engine which renders pages. Above that are the renderer process (simplistically, -one-per-tab), each of which contains one Blink instance. Managing all the -renderers is the browser process, which controls all network accesses. - -[<img alt="image" -src="/developers/design-documents/multi-process-resource-loading/Resource-loading.png">](/developers/design-documents/multi-process-resource-loading/Resource-loading.png) - -## Blink - -Blink has a `ResourceLoader` object which is responsible for fetching data. Each -loader has a `WebURLLoader` for performing the actual requests. The header file -for this interface is inside the Blink repo. - -`ResourceLoader` implements the interface `WebURLLoaderClient`. This is the -callback interface used by the renderer to dispatch data and other events to -Blink. - -The test shell uses a different resource loader, so provides a different -implementation, non-IPC version ~~of `ResourceLoaderBridge`, located in -`webkit/tools/test_shell/simple_resource_loader_bridge`~~. - -## Renderer - -The renderer's implementation of `WebURLLoader`, called `WebURLLoaderImpl`, is -located in `content/child/`. It uses the global `ResourceDispatcher` singleton -object (one for each renderer process) to create a unique request ID and forward -the request to the browser via IPC. Responses from the browser will reference -this request ID, which can then be converted back to the `RequestPeer` object -(WebURLRequestImpl) by the resource dispatcher. - -## Browser - -The `RenderProcessHost` objects inside the browser receive the IPC requests from -each renderer. It forwards these requests to the global -`ResourceDispatcherHost`, using a pointer to the render process host -(specifically, an implementation of `ResourceDispatcherHost::Receiver`) and the -request ID generated by the renderer to uniquely identify the request. - -Each request is then converted into a `URLRequest` object, which in turn -forwards it to its internal `URLRequestJob` that implements the specific -protocol desired. When the `URLRequest` generates notifications, its -`ResourceDispatcherHost::Receiver` and request ID are used to send the -notification to the correct `RenderProcessHost` for sending back to the -renderer. Since the ID generated by the renderer is preserved, it is able to -correlate all responses with a specific request first generated by Blink. - -## Cookies - -All cookies are handled by our `CookieMonster` object in `/net/base`. We do not -share cookies with other browsers' network stacks (e.g. WinINET or Necko). The -cookie monster lives in the browser process which handles all network requests -because cookies need to be the same across all tabs. - -Pages can request cookies for a document via `document.cookie`. When this -occurs, we send a synchronous message from the renderer to the browser -requesting the cookie. While the browser is processing the cookie, the thread -that Blink works on is suspended. When the renderer's I/O thread receives the -response from the browser, it un-suspends the thread and passes the result back -to the JavaScript engine.
\ No newline at end of file |