My kingdom for Tab Groups! https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...
Fearless Concurrency in Firefox Quantum
101–110 of 177 posts
Re: Fearless Concurrency in Firefox Quantum
#102Is it a concern that acid3 test as terribly faild? - http://acid3.acidtests.org/
I'm sorry? I just scored a 97/100 using FF v57.0 x64. That's decent right? The newest version of Chrome fails likewise.
Also this:
>Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers. The tests remain available for historical purposes and for use by browser vendors. It would be inappropriate, however, to use them as part of a certification process, especially for mobile browsers.[0]
Re: Fearless Concurrency in Firefox Quantum
#103Is it a concern that acid3 test as terribly faild? - http://acid3.acidtests.org/
Both firefox dev edition and chrome (mac) score 97 for me.
Re: Fearless Concurrency in Firefox Quantum
#104Earlier quoted context omitted.
I hate that phrase and its reflexive usage so much. Yes, a bad workman blames his tools, but so does a good workman using lousy tools.
You can respond with "that's because a good workman doesn't use poor tools." It nicely suggests that maybe it's the programmer's responsibility to advocate for something better.
When I was a kid I used to pride myself on how many things I could take apart and reassemble with just a butter knife. But that was only because I didn't have access to real screwdrivers.
Likewise with software, each improved tool I learn (or new but worse tool I learn to avoid) makes me appreciate how much time I could have been wasting by using inferior tools/practices/languages.
Re: Fearless Concurrency in Firefox Quantum
#105Could 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 t…
But you can implement the same abstraction in C++. It bugs me when people tout library features as language features.
Re: Fearless Concurrency in Firefox Quantum
#106Re: Fearless Concurrency in Firefox Quantum
#107Earlier quoted context omitted.
Thanks! Yes, when you construct a mutex, you give it ownership of the vector you want it to protect. Due to the way Rust works, once you've given ownership to something else, you can no longer access it yourself. The only way you can get access to the data again is to "borrow" a reference to it, but this borrow has a "lifetime", which is tied to the period for which you're holding the mutex. This is how the compiler…
Yeah that makes sense! It strikes me as pretty similar to volatile-correctness in C++ (it's a technique -- look it up if you haven't heard of it) with the additional constraint that there is only ever one mutable reference, for better or for worse.
For cases where you need more than one mutable reference, you can use `Cell` (single-threaded) or atomics, which allow mutation through shared references.
Re: Fearless Concurrency in Firefox Quantum
#108Earlier quoted context omitted.
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 t…
But you can implement the same abstraction in C++. It bugs me when people tout library features as language features.
You can't implement it soundly.
Re: Fearless Concurrency in Firefox Quantum
#109Re: Fearless Concurrency in Firefox Quantum
#110Earlier quoted context omitted.
But you can implement the same abstraction in C++. It bugs me when people tout library features as language features.
You can't implement it soundly.
Define "soundly". Follow the rules and it won't break. Will it break if someone memcpys some object internals or something? Sure. Just don't do that. The rules that make this abstraction robust in C++ are easy to follow, just like the rule that says "don't use unsafe" in Rust. Just like Rust, you can break the rule if you know what you're doing.