3 ms·

That's what they're doing now and it's the problem, not the solution. Multiple threads run in the same process address space. This creates security and stabili

by deprave 10y ago

That's what they're doing now and it's the problem, not the solution. Multiple threads run in the same process address space. This creates security and stability issues. One website can affect the complete experience. That's exactly the problem they're trying to solve, the same way Chrome did, by using multiple processes. That way, for example, when one process misbehaves and gobbles up too much memory, the OS won't kill the entire browser but just the offending tab. (The OS won't kill individual threads.)

the8472 10y ago
> security and stability That's shifting goalposts. GP quoted that it's about responsiveness and resource consumption. And resource consumption is obviously lower with multi-threading since more data structures can be shared.
- deprave 10y ago
  That's not shifting goalposts, that's the goal from the start. You seem to be throwing a lot of technical terms. Could you elaborate on where exactly do you see overhead coming from in a multiprocess vs. multithread architecture? And which data structures can be shared between threads but not between processes? Scheduling overhead is identical and pure OS memory overhead is slightly higher for processes (they need more "accounting" data), but everything else can be optimized at the application level. Furthermore, shared memory lets you share data structures between processes just fine (heck, some data can be shared between processes and the kernel!), and since I assume the content processes will be dynamically linked, you're not even going to load shared libraries multiple times.
  - the8472 10y ago
    > shared memory lets you share data structures between processes In theory maybe. In practice data structures contain pointers, which you can't just shove into cross-process shared memory. Which in turn results in copying things and serialization/deserialization overhead when doing IPC. With multi-threading you can just share regular data structures (think std::map) and put them under locks or copy-on-write logic if they need to be modified. Of course you can share some large blobs, like pixel data or loaded files. But the major data churn consisting of many small, nested data structures involves copying and (de)serializing.
piotrjurkiewicz 10y ago
The author justifies introduction of e10s using an example of inter-tab CPU contention. Yes, this is a real problem, I experience it using Firefox. But for that particular issue, a sufficient solution is multithreading. As you wrote, separating each tab into a different process will bring security and stability benefits. But blog post author does not mention any of them. The only justification for e10s he brings up is CPU-UI blocking problem (which is not a justification for e10s at all, because it can be solved with multithreading). And there is a reason why he doesn't mention security and stability benefits: They do not plan [1] (at least for now) separating each tab into a different process. All tabs will still share the same content process. This means that e10s would not bring any security and stability benefits you wrote about. So one may ask: what's the point in introduction of e10s at all? I ask myself this question as well, not only regarding e10s, but also many other Mozilla decisions from last few years. [1]: https://wiki.mozilla.org/Electrolysis/Multiple_content_processes https://wiki.mozilla.org/Electrolysis/Multiple_content_proce...
- majewsky 10y ago
  They say that they want to move to multiple content processes, so I guess that their end goal is still one content process per tab. Also, another reason for e10s is to decouple the rendering engine from the UI parts, in order to a) get rid of XUL and b) offer a path for replacing Gecko with Servo once Servo's ready for primetime.
  - piotrjurkiewicz 10y ago
    > a) get rid of XUL And the same time break tens thousands of extensions (which are the main reason why most Firefox users still use this browser).
- deprave 10y ago
  Have you ever seen the source base of a browser like Firefox or Chrome? You must do small incremental improvements if you want your software to continue to work. The hardest part is disentangling everything from a single process architecture to multiprocess. That's what they're doing now. Switching from a single content process to multiple content processes is significantly easier. I don't understand how you conclude that "they do not plan separating each to into a different process" from the link you posted given it opens with "After e10s is enabled for all users, the next step is to introduce multiple content processes." To answer your question, then, the point of introducing e10s is to make it easier to switch from a single process to multiprocess architecture.

by deprave 10y ago

the8472 10y ago

> security and stability That's shifting goalposts. GP quoted that it's about responsiveness and resource consumption. And resource consumption is obviously lower with multi-threading since more data structures can be shared.

deprave 10y ago
That's not shifting goalposts, that's the goal from the start. You seem to be throwing a lot of technical terms. Could you elaborate on where exactly do you see overhead coming from in a multiprocess vs. multithread architecture? And which data structures can be shared between threads but not between processes? Scheduling overhead is identical and pure OS memory overhead is slightly higher for processes (they need more "accounting" data), but everything else can be optimized at the application level. Furthermore, shared memory lets you share data structures between processes just fine (heck, some data can be shared between processes and the kernel!), and since I assume the content processes will be dynamically linked, you're not even going to load shared libraries multiple times.
- the8472 10y ago
  > shared memory lets you share data structures between processes In theory maybe. In practice data structures contain pointers, which you can't just shove into cross-process shared memory. Which in turn results in copying things and serialization/deserialization overhead when doing IPC. With multi-threading you can just share regular data structures (think std::map) and put them under locks or copy-on-write logic if they need to be modified. Of course you can share some large blobs, like pixel data or loaded files. But the major data churn consisting of many small, nested data structures involves copying and (de)serializing.

piotrjurkiewicz 10y ago

The author justifies introduction of e10s using an example of inter-tab CPU contention. Yes, this is a real problem, I experience it using Firefox. But for that particular issue, a sufficient solution is multithreading. As you wrote, separating each tab into a different process will bring security and stability benefits. But blog post author does not mention any of them. The only justification for e10s he brings up is CPU-UI blocking problem (which is not a justification for e10s at all, because it can be solved with multithreading). And there is a reason why he doesn't mention security and stability benefits: They do not plan [1] (at least for now) separating each tab into a different process. All tabs will still share the same content process. This means that e10s would not bring any security and stability benefits you wrote about. So one may ask: what's the point in introduction of e10s at all? I ask myself this question as well, not only regarding e10s, but also many other Mozilla decisions from last few years. [1]: https://wiki.mozilla.org/Electrolysis/Multiple_content_processes https://wiki.mozilla.org/Electrolysis/Multiple_content_proce...

majewsky 10y ago
They say that they want to move to multiple content processes, so I guess that their end goal is still one content process per tab. Also, another reason for e10s is to decouple the rendering engine from the UI parts, in order to a) get rid of XUL and b) offer a path for replacing Gecko with Servo once Servo's ready for primetime.
- piotrjurkiewicz 10y ago
  > a) get rid of XUL And the same time break tens thousands of extensions (which are the main reason why most Firefox users still use this browser).
deprave 10y ago
Have you ever seen the source base of a browser like Firefox or Chrome? You must do small incremental improvements if you want your software to continue to work. The hardest part is disentangling everything from a single process architecture to multiprocess. That's what they're doing now. Switching from a single content process to multiple content processes is significantly easier. I don't understand how you conclude that "they do not plan separating each to into a different process" from the link you posted given it opens with "After e10s is enabled for all users, the next step is to introduce multiple content processes." To answer your question, then, the point of introducing e10s is to make it easier to switch from a single process to multiprocess architecture.