Fearless Concurrency in Firefox Quantum

Post by duneroadrunner » Wed, Nov 15, 2017, 9:22 PM UTC

ekidd wrote: post #45

kibwen wrote: post #8

I like this explanatory comment by Manishearth, a Servo dev, in the thread over on /r/rust: "This blog post brought to you by the 'how many times can you say 'fearless concurrency' and keep a straight face' cabal. "Seriously though, I now appreciate that term a lot more. One thing that cropped up in the review of this post was that I didn't have examples of bugs Rust prevented. Because I couldn't think of any concret…

I've spent the last few days aggressively parallelizing some Rust code with crossbeam, and it's really just... painless (once you're used to Rust). Rust actually understands data races, and it grumbles at me until my code is provably safe, and then everything Just Works. The Rayon library is also lovely for data parallelism. Sometimes, I think, "Rust is basically a nicer C++ with the obvious foot guns removed and gre…

Post by pcwalton » Wed, Nov 15, 2017, 9:42 PM UTC

quotemstr wrote: post #110

pcwalton wrote: post #108

Earlier quoted context omitted.

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.

Post by wtetzner » Wed, Nov 15, 2017, 9:47 PM UTC

vanderZwan wrote: post #126

kenhwang wrote: post #115

Earlier quoted context omitted.

"Warn" is nicer phrasing than what the compiler actually does. Rust's compiler will straight up refuse to compile your code if it thinks it has a concurrency bug in it.

> if it thinks it has a concurrency bug in it. This makes it sound like it is wrong sometimes. I'm not using Rust, if this is what you meant, could you give examples of that?

Post by duneroadrunner » Wed, Nov 15, 2017, 11:07 PM UTC

maffydub wrote: post #39

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

    template
    void write_foo(TVectorPointer vec_ptr) {
        (*vec_ptr)[3] += 1;
    }
    
    template
    auto read_foo(TVectorPointer vec_ptr) {
        return (*vec_ptr)[7];
    }
    
    template
    void use_shared_vector(TVectorAccessRequester vec_ar) {
        {
            // obtain a non-const pointer to the vector from the "access requester"
            // blocking if necessary
            auto wl_ptr = vec_ar.writelock_ptr();

            write_foo(wl_ptr);

            // the pointer owns a lock on the vector so as long as the pointer
            // exists it is safe and valid to use
        }

        // obtaining and using a const pointer to the vector
        auto res1 = read_foo(vec_ar.readlock_ptr());
        
        // without a "lock pointer" obtained from an access requester, there is no way
        // to access, or even refer to the shared vector, so you can't access it in an
        // unsafe manner
    }

Post by vatotemking » Thu, Nov 16, 2017, 12:16 AM UTC

Manishearth wrote: post #124

vatotemking wrote: post #82

Earlier quoted context omitted.

Perhaps you're on an older version of FF, no? Because the things you mentioned are present, just not an exact UI/UX as that with Chrome. Im on FF Quantum 57.0 (non dev, vanilla FF) and here are my observations: > When an XHR response comes back as HTML, there is no "Preview" tab like in Chrome. This is consolidated in the Response tab. You can view it as raw response, or JSON (with filtering options). > Also, the res…

For XHR there's also an "edit and resend" button as well as "copy as cURL" which is amazing