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.)

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.

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.

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.

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_proce...

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.

And the same time break tens thousands of extensions (which are the main reason why most Firefox users still use this browser).

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.

So per-tab content processes (which btw is the only way e10s can result in security and stability benefits) is not a realistic goal for them.

People always say that as if crashes would be a regular thing happening every few minutes. I don't experience browser crashes for days, so I find it kind of odd that such a relatively rare failure case is considered a good justification for using a process per tab.

I used OneTab for a while, to reduce memory use, but still found Firefox more efficient and more stable with hundreds of tabs, mainly because the vast majority weren't actually loaded until I needed them.

It's not hard to crash Firefox -- just keep loading an infinite page of gifs etc. But once you know that, you don't do it.

Under normal working conditions, I agree: none of the main browsers crashes often enough for it to be a problem.

(Even process-per-tab is not perfect for security: a compromised page from one origin could open an iframe to another origin.)

IPC, shared memory, and credentials/descriptor passing are common patterns that exist in tons of software today. OpenSSH, Postfix, probably every iOS app.

Multithreading is great, but it's not suitable for a browser that may be fed malicious code and has a huge attack surface.

Yes, in those simple terms, it would be 1) simpler to coordinate multiple threads in the same process compared to multiple processes, and 2) more efficient too.

1 is true because any system you might use to communicate between processes would involve an IPC layer and with a single process, you could use an identical system with the IPC removed.

2 is true because multiple threads in the same process can communicate directly without requiring IPC (which requires data serialization, shared memory for performance, and more system calls). i.e, sharing data has much higher cost using IPC. You can skip some serialization if you use shared memory, but you still need to set that up and manage shared buffers. (Different applications might share data in different ways so that the IPC overhead becomes negligible, but non-IPC could always be implemented faster.)

But the benefit gained from using multiple processes for a web browser (that is essentially a VM for running untrusted JS/web code) is security in the face of bugs. It comes from how operating systems provide tried-and-tested process isolation. If sites from separate origins are rendered or parsed in their own process, some types of browser bugs are harder to exploit to gain access to data from other origins. And for bugs that just cause crashes without security implications, you can crash a single tab and let other tabs continue, let the main UI continue.

On its own, that is good, but not great.

The big benefit is that the big 3 operating systems that browser developers are concerned with provide some level of per-process sandboxing. For example, one can launch a process with a limited set of privileges such that the only thing that process is allowed to do is communicate via IPC and compute stuff. The operating system enforces this for you. Provided you have a strong IPC layer, a process with such limited privileges can do very little damage if it is compromised.

Developing a strong IPC layer is not extremely difficult as it essentially boils down to reading a stream of messages from an untrusted source and detecting invalid messages without compromising yourself.

> And for bugs that just cause crashes without security implications, you can crash a single tab and let other tabs continue, let the main UI continue.

That's using non-security bugs as an argument for increasing memory footprint. It would be preferable to have those bugs fixed instead.

> Developing a strong IPC layer is not extremely difficult as it essentially boils down to reading a stream of messages from an untrusted source and detecting invalid messages without compromising yourself.

That's implementation complexity. But you also have to consider the performance overhead of proxying method access to arbitrary objects and bouncing each method invocation and its results back and forth. That's needed for backwards compatibility with addon code unaware of the process separation.

https://developer.mozilla.org/en-US/Firefox/Multiprocess_Fir...