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

Fearless Concurrency in Firefox Quantum

blog.rust-lang.org

Post reply on HN
Print view View original

31–40 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#31

Post by giancarlostoro »

MaxBarraclough wrote: post #17
ape4 wrote: post #11

The new Firefox is actually faster.

My only complaint is the marketing. Firefox isn't slow, sure enough. But it wasn't slow last week either. I've been using it as my primary browser for a long time, and performance was never an issue. Also, 'Quantum'? Come on now. If they're aiming Firefox at power-users (which they should be), they should know that kind of buzzword abuse is only going to annoy.

I agree, to me Firefox and Chrome were both seemingly to the naked eye for me at about the same speed but now I notice some pages Chrome chokes up on Firefox just keeps on rolling along. As for the Quantum comment, I just think of Nuka Cola Quantum and it amuses me a bit, but maybe I just play a little too much Fallout 4.

Re: Fearless Concurrency in Firefox Quantum

#32

Post by Cyph0n »

s_kilk wrote: post #25
MaxBarraclough wrote: post #17

Earlier quoted context omitted.

My only complaint is the marketing. Firefox isn't slow, sure enough. But it wasn't slow last week either. I've been using it as my primary browser for a long time, and performance was never an issue. Also, 'Quantum'? Come on now. If they're aiming Firefox at power-users (which they should be), they should know that kind of buzzword abuse is only going to annoy.

Firefox was, up until today, noticeably slower than Chrome. Today it's faster.

Especially on Mac. In my experience, FF on Windows was pretty snappy. Quantum is on a whole other level though.

Re: Fearless Concurrency in Firefox Quantum

#33

Post by JosephRedfern »

asadjb wrote: post #19
MaxBarraclough wrote: post #17

Earlier quoted context omitted.

My only complaint is the marketing. Firefox isn't slow, sure enough. But it wasn't slow last week either. I've been using it as my primary browser for a long time, and performance was never an issue. Also, 'Quantum'? Come on now. If they're aiming Firefox at power-users (which they should be), they should know that kind of buzzword abuse is only going to annoy.

Anecdotal evidence, so take it with a grain of salt. I switched to Firefox 2 days ago, after reading a post about how Firefox has recently got faster. I have been a Chrome user for more than a couple of years now, when I switched from Firefox because it was slow in comparison. After using Firefox for 1 day, it already seemed slower than what I was used to in Chrome. This was most noticeable on ad-laden sites that dis…

Exactly the same situation here. As a new (returned) FF user, v57 is noticeable faster than v56.

Re: Fearless Concurrency in Firefox Quantum

#34

Post by seren »

throwaway613834 wrote: post #30

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.) EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to…

The most basic example would be two threads trying to write the same variable concurrently without synchronisation. As far as I know, as long as you don't use any unsafe code block, it is not possible, i.e. the compiler will protest loudly and the program won't compile.

You are forced by the compiler to implement an explicit exclusion mechanism.

The point is that kind of issue are silent bugs most of the time(up to point) in C, C++. It can work in most cases, and one day, something goes awfully wrong because the thread scheduling is slightly different than usual.

Re: Fearless Concurrency in Firefox Quantum

#35

Post by twic »

rkangel wrote: post #15
pimeys wrote: post #10

Earlier quoted context omitted.

I've built now several concurrent services with Rust. The language definitely gives confidence to try several things with different approaches to concurrency. None of my services crash (except once per 3-4 months when I deployed something "that will never crash" using `.unwrap()`). The crashes are always my own laziness, but if I follow the pattern of checking return values and unwraping only when the input is static…

Note that the panic you get by calling unwrap() where you shouldn't isn't a crash. It's a controlled program exit due to an unexpected condition. While yes, the panic will cause your program to stop, it will do it in a clean deterministic way (with a backtrace). Actual crashes (due to segfaults) can happen a long way from the bug that actually caused the issue, can happen intermittently and generally be a nightmare t…

When this controlled program exit happens, does your monitoring system wake your operations staff up? If so, it's a crash.

Re: Fearless Concurrency in Firefox Quantum

#36

Post by majewsky »

throwaway613834 wrote: post #30

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.) EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to…

Many (most?) of the non-deterministic bugs in concurrent programs arise from two threads trying to write to the same place in the same time, or one thread writing to one place while the other thread just read that place and assumed that it was going to be constant for the moment.

Rust prevents that by having the concepts of "ownership" and "borrowing" built into the language. The Rust book probably explains this better than I ever could, but the basic idea is that you can only have one actor writing to a variable, OR any number of actors reading a variable. But you cannot have multiple actors having write access the same variable at the same time, or one actor writing to it while anyone has read access to it, unless you use some sort of serialization or copy-on-write mechanism.

Re: Fearless Concurrency in Firefox Quantum

#37

Post by TheCycoONE »

throwaway613834 wrote: post #30

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.) EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to…

Sure, the obvious example is your classic thead1 i++, thead2 i-- bug. In C you run each thread a large number of times in parallel and you end up with something other than 0. The solution is to use atomic operations or locks.

Rust doesn't allow having two mutable references to the same memory location at the same time, so you would never encounter that.

Re: Fearless Concurrency in Firefox Quantum

#38

Post by vatotemking »

Firefox Quantum is blazing fast, and I finally ditched Chrome.

My only problem is that it drains my battery life fast. So whenever I'm not plugged I use Edge. Other than that, FF is amazing.

It is now my default browser and I even wrote a FF add-on a few days ago using their new API!

Re: Fearless Concurrency in Firefox Quantum

#39

Post by maffydub »

throwaway613834 wrote: post #30

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.) EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to…

Borrowing from https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... (linked to from the original post), the following code tries to access a lock-protected vector.

    fn use_lock(mutex: &Mutex>) {
        let vec = {
            // acquire the lock
            let mut guard = lock(mutex);
    
            // attempt to return a borrow of the data
            access(&mut guard)
    
            // guard is destroyed here, releasing the lock
        };
    
        // attempt to access the data outside of the lock.
        vec.push(3);
    }
It doesn't compile because the lock is not held long enough.

    error: `guard` does not live long enough
    access(&mut guard)
                ^~~~~
There are several more examples in that article, but you can read them there rather than here!

Re: Fearless Concurrency in Firefox Quantum

#40

Post by throwaway613834 »

TheCycoONE wrote: post #37
throwaway613834 wrote: post #30

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.) EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to…

Sure, the obvious example is your classic thead1 i++, thead2 i-- bug. In C you run each thread a large number of times in parallel and you end up with something other than 0. The solution is to use atomic operations or locks. Rust doesn't allow having two mutable references to the same memory location at the same time, so you would never encounter that.

> Rust doesn't allow having two mutable references to the same memory location at the same time, so you would never encounter that.

Wouldn't that make a whole class of efficient algorithms impossible though? Like let's say you have an std::list and you want a sorted "view" of the elements. In C++ you'd create an array of pointers and then sort it, and after that you can just modify whatever each slot points to. In Rust you... can't do that because they'd all need to be read-only? I don't imagine you can turn the read-only to read-write on a whim (otherwise if you do this with two of them how the hell would the compiler figure out if two of them point to the same slot?) so the whole thing is just impossible?

Post reply on HN