Hacker News Reader

Comment by deprave | Hacker News Reader

The goal must be a single controller ("UI") process and multiple content processes for each tab, otherwise they'll be missing out on the advantages of a multiprocess model, namely, stability and isolation.

They're first going to do two processes, probably for debugging without too many moving parts, then multiprocess. See https://wiki.mozilla.org/Electrolysis#Schedule_and_Status and https://wiki.mozilla.org/Electrolysis/Multiple_content_proce....

View on HN

It's not supported, but you can go into about:config and change dom.ipc.processCount to a number higher than one. I haven't had any trouble running at the number of hardware threads, minus one for the UI.

Ok now that I've read all the problems that could cause https://bugzilla.mozilla.org/showdependencytree.cgi?id=e10s-... , I feel bad about recommending it.

> The goal must be [...] multiple content processes for each tab

According to the wiki page you linked, it doesn't seem to be the goal for them:

"The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either."

If this is true, I don't see any advantages of e10s introduction.

They're going to find out that managing processes by themselves is going to be very difficult (similar to M:N threading), and opt for a Chrome-like model where each tab is its own process.

That was the original Chrome model but they switched to M:N.

I don't think going full process per tab is the answer either, I think that some kind of system that adds additional processes for heavy tabs while keeping as many on single content processes would be a good middle ground.

Reply on news.ycombinator.com