Not sure why we need this. Without plugins (flash, java, silverlight) , firefox IS pretty stabled.
It's needed to attract the die hard Chrome users back to Firefox.
Multiprocess Firefox
51–60 of 126 posts
Re: Multiprocess Firefox
#52> All IPC happens using the Chromium IPC libraries
Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.
Re: Multiprocess Firefox
#53It's unfortunate how behind the curve Mozilla is on this. No denying this was a huge undertaking but the length of time it's taken has obviously been detrimental to Firefox usage, the only real reason I still use Chrome as my primary browser. Though I'll give Electrolysis a shot with Firefox Nightly and see how it works out.
Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
Re: Multiprocess Firefox
#54> All IPC happens using the Chromium IPC libraries Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.
If someone's already written a perfectly good solution that's readily available you either
- pridefully write your own
- use theirs
Re: Multiprocess Firefox
#55Earlier quoted context omitted.
My C code doesn't share heaps. Strict privsep design meaning one heap per process and no threads in favour of "select".
Well, OS processes are the obvious solution. I was asking about languages/runtimes that feature that as a default. > and no threads in favour of "select". Not sure why you mentioned that. Callback chains can create concurrency contexts (callback chains) that can interfere with each other, much like multiple threads would. It would have a much higher granularity but you are not out of the woods.
Only because I usually end up knocking up network servers.
That is true but you only have one thread to synchronise so mutexes and locks are vastly simplified.
Re: Multiprocess Firefox
#56For those of you interested in parallelism in browsers, I suggest you keep an eye on Mozilla's experimental new browser engine, Servo.[1] The goal is to make use of a variety of concurrency strategies (such as a Chrome-esque process-per-tab design[2]) and Rust's built-in support for memory-safe concurrency abstractions (fork/join, lightweight tasks, SIMD, etc.) to produce a ludicrously parallel[3] web browser. And ev…
I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.
Hahaha, you and me and about 1% of the browser users (well on HN, probably more like 10%) have particular habits of keeping much larger numbers of tabs open than everyone else.
Have you imagined an alternate scheme to tabs, where there are 100s of thousands of potential "tabs" which can be organized, called up in groups, moved in clumps together, and shared?
Imagine each group of tabs like soldiers in a Command and Conquer game...
Re: Multiprocess Firefox
#57It's unfortunate how behind the curve Mozilla is on this. No denying this was a huge undertaking but the length of time it's taken has obviously been detrimental to Firefox usage, the only real reason I still use Chrome as my primary browser. Though I'll give Electrolysis a shot with Firefox Nightly and see how it works out.
Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
You have a good point about switching cost. On the other hand, Chrome always could be run with --single-process (mainly there to measure the overhead of multiprocess), so it didn't really "pick one".
Re: Multiprocess Firefox
#58It's unfortunate how behind the curve Mozilla is on this. No denying this was a huge undertaking but the length of time it's taken has obviously been detrimental to Firefox usage, the only real reason I still use Chrome as my primary browser. Though I'll give Electrolysis a shot with Firefox Nightly and see how it works out.
Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
Electrolysis was stalled and/or deprioritized for something like two years, with no apparent progress.
Re: Multiprocess Firefox
#59I'm very excited about this. I usually drive Firefox Beta without any sorts of complaints, but installed nightly just to try this out live. With my list of extensions[1] this doesn't seem to be particularly stable. It fails to bring up my tabs from last time. That would be OK for experimentation, had it not been for the fact that it also crashes regularly. These two combined really is test-stopper for me. Note: I'm n…
Are the crashes listed in Firefox's about:crashes page? Filing bug reports with those crash IDs (which reference stack traces on crash-stats.mozilla.com) would be a big help.
Firebug might be a problem because it is tightly coupled to Firefox's internal debugging APIs.
Re: Multiprocess Firefox
#60My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the ot…
Are you comparing cold start times? Don't IE and Chrome launch a "quick start" background process when you boot Windows?