Confirmed users
165
edits
Multiprocess Images: Difference between revisions
→Issues and Questions
(Created page with '== Overview == The Electrolysis project is in full swing, and so we should soon have the capability to run each tab as a separate content processes. This i...') |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
The [[Content Processes|Electrolysis]] project is in full swing, and so we should soon have the capability to run each tab as a separate content processes. This impacts everything that is normally shared among tabs, and the image cache is no exception. Currently, all requests for images from content-land go through the shared imgLoader. The imgLoader owns the actual imgRequest, and it hands out imgRequestProxies that act as handles for interested callers. Depending on whether the image data is in the cache, these handles point to imgContainers that contain all, some, or none of the data (in the latter two cases, the containers are asynchronously filled by data from the network, as it arrives). | The [[Content Processes|Electrolysis]] project is in full swing, and so we should soon have the capability to run each tab as a separate content processes. This impacts everything that is normally shared among tabs, and the image cache is no exception. Currently, all requests for images from content-land go through the shared imgLoader. The imgLoader owns the actual imgRequest, and it hands out imgRequestProxies that act as handles for interested callers. Depending on whether the image data is in the cache, these handles point to imgContainers that contain all, some, or none of the data (in the latter two cases, the containers are asynchronously filled by data from the network, as it arrives). | ||
A simple solution for images in a content-process world is to run a separate imgLoader (requests + cache) in each content process. This is undesirable | A simple solution for images in a content-process world is to run a separate imgLoader (requests + cache) in each content process. This is undesirable, because it means we can end up downloading and decoding the same image multiple times unnecessarily (TODO-elaborate). | ||
Some of these effects may be ameliorated by the necko-layer cache. If someone with a good understanding of how that works wants to weigh in, your input would be appreciated. Furthermore, these effects are highly dependant on browsing patterns. This point is crucial, because they won't show up on Tp assuming pages are loaded sequentially in the same content process. We should investigate a way to measure performance in this regard, perhaps with the help of browsing pattern statistics from | Some of these effects may be ameliorated by the necko-layer cache. If someone with a good understanding of how that works wants to weigh in, your input would be appreciated. Furthermore, these effects are highly dependant on browsing patterns. This point is crucial, because they won't show up on Tp assuming pages are loaded sequentially in the same content process. We should investigate a way to measure performance in this regard, perhaps with the help of browsing pattern statistics from Test Pilot. | ||
A better solution involves sharing the imgLoader, in effect creating an "image server" that the content processes would interface with over IPC to do the image loading. This could either run in the chrome process or in an entirely separate process. This is one thing that needs to be decided. Since all the networking is happening in the chrome process, it would probably make the most sense to do it there (so that the incoming data doesn't have to jump processes twice). However, it's possible that security advantages or the performance gains on multicore cpus of decoding in a separate process could outweigh this. | A better solution involves sharing the imgLoader, in effect creating an "image server" that the content processes would interface with over IPC to do the image loading. This could either run in the chrome process or in an entirely separate process. This is one thing that needs to be decided. Since all the networking is happening in the chrome process, it would probably make the most sense to do it there (so that the incoming data doesn't have to jump processes twice). However, it's possible that security advantages or the performance gains on multicore cpus of decoding in a separate process could outweigh this. | ||
| Line 50: | Line 47: | ||
* If a content process goes down, are we guaranteed by the IPC mechanism to hear about it? If not, what do we do when a client goes down without releasing the proxy hold on an image in the server cache? | * If a content process goes down, are we guaranteed by the IPC mechanism to hear about it? If not, what do we do when a client goes down without releasing the proxy hold on an image in the server cache? | ||
* How does all this fit into the existing security architecture? | * How does all this fit into the existing security architecture? | ||
* Do we want to map the shmem regions individually or use one big region? | * Do we want to map the shmem regions individually or use one big region? | ||
** Is it a violation of the eventual security model if one content process can read (not write) the image data of other processes? This would effectively nix the one-big-region strategy. | ** Is it a violation of the eventual security model if one content process can read (not write) the image data of other processes? This would effectively nix the one-big-region strategy. | ||