Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiprocess Firefox

billmccloskey.wordpress.com

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Multiprocess Firefox

#41

Post by pmarin »

rdtsc wrote: post #13
csmuk wrote: post #7

Earlier quoted context omitted.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…

>Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more?

Tcl runs an interpreter per thread and communicate each other using message passing.

Re: Multiprocess Firefox

#42

Post by rdtsc »

csmuk wrote: post #27
rdtsc wrote: post #13

Earlier quoted context omitted.

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…

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.

Re: Multiprocess Firefox

#43

Post by pwnna »

fenesiistvan wrote: post #15

My 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…

Do you have stats? Go to Help => Firefox Health Report and look at the data on startup time and so forth.

I seem to remember that there are things you can do if you deviate too much from the average of others.. but I don't remember where to find that info.

Re: Multiprocess Firefox

#44

Post by deeringc »

RHSeeger wrote: post #35
kibwen wrote: post #23

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

It seems to me that "one process per window" would make it very difficult to implement dragging tabs between windows, and out into their own window.

Re: Multiprocess Firefox

#45

Post by RunningDroid »

ritonlajoie wrote: post #38

From a code maintainance point of view, how do you manage to keep this 'branch' in track with the main one ? I mean, every patch made to the real firefox has to be carefully reviewed and backported to this multiprocess branch. Is that a manual process ? Or can it be automated like that : 1) Check if new commit arrived on 'head' 2) Auto backport it to the multiprocess branch 3) Try a build + run tests. Everything look…

The multiprocess code is in the main branch, just not enabled by default.

Re: Multiprocess Firefox

#46

Post by coyotebush »

ritonlajoie wrote: post #38

From a code maintainance point of view, how do you manage to keep this 'branch' in track with the main one ? I mean, every patch made to the real firefox has to be carefully reviewed and backported to this multiprocess branch. Is that a manual process ? Or can it be automated like that : 1) Check if new commit arrived on 'head' 2) Auto backport it to the multiprocess branch 3) Try a build + run tests. Everything look…

Since multiprocess is in the regular Nightly, the code is in the main line of development (mozilla-central). Based on the preference, it decides at runtime how to handle the content/chrome interface.

But when Mozilla does branch off separate trees, VCS merges and lots of automated tests are largely sufficient.

Re: Multiprocess Firefox

#47

Post by efuquen »

It'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.

Re: Multiprocess Firefox

#48

Post by pekk »

mariusmg wrote: post #39

Not sure why we need this. Without plugins (flash, java, silverlight) , firefox IS pretty stabled.

Do you honestly think it is reasonable to expect everyone not to use any plugins? Let me know how they are going to, say, get audio from webapps.

I guess everything is stable, if you just avoid all the features everyone uses.

Re: Multiprocess Firefox

#49

Post by woozy »

kibwen wrote: post #23

For 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…

Ah, Rust behind the scene. I sensed that correlation.
Post reply on HN