8

This is a continuation of How to re-use a value from the outer scope inside a closure in Rust? , opened new Q for better presentation.

// main.rs

    // The value will be modified eventually inside `main` 
    // and a http request should respond with whatever "current" value it holds.
    let mut test_for_closure :Arc<RefCell<String>> = Arc::new(RefCell::from("Foo".to_string()));

// ...

    // Handler for HTTP requests
    // From https://docs.rs/hyper/0.14.8/hyper/service/fn.service_fn.html
    let make_svc = make_service_fn(|_conn| async {
        Ok::<_, Infallible>(service_fn(|req: Request<Body>| async move {
            if req.version() == Version::HTTP_11 {
                let foo:String = *test_for_closure.borrow();
                Ok(Response::new(Body::from(foo.as_str())))
            } else {
                Err("not HTTP/1.1, abort connection")
            }
        }))
    });

Unfortunately, I get RefCell<std::string::String> cannot be shared between threads safely:

enter image description here

rollingBalls
  • 1,808
  • 1
  • 14
  • 25
  • Do you clone your Arc ? This part isn't visible in your code. See [cloning Arc references](https://doc.rust-lang.org/std/sync/struct.Arc.html#cloning-references). – Denys Séguret Jun 07 '21 at 19:05
  • 1
    Please copy errors as **text** in the question. Don't include them as screenshots: images may be hard to read depending on the viewer's screen resolution and can't be searched by other people with similar problems. – Jmb Jun 08 '21 at 06:22

2 Answers2

6

RefCell only works on single threads. You will need to use Mutex which is similar but works on multiple threads. You can read more about Mutex here: https://doc.rust-lang.org/std/sync/struct.Mutex.html.

Here is an example of moving an Arc<Mutex<>> into a closure:

use std::sync::{Arc, Mutex};

fn main() {
    let mut test: Arc<Mutex<String>> = Arc::new(Mutex::from("Foo".to_string()));

    let mut test_for_closure = Arc::clone(&test);
    let closure = || async move {
        // lock it so it cant be used in other threads
        let foo = test_for_closure.lock().unwrap();
        println!("{}", foo);
    };
}
C. Lang
  • 463
  • 4
  • 12
  • Thank you very much again! There's still some kind of black magic involved because now the borrowed value does not live long enough. I made a follow up Q, if you would like to take a look: https://stackoverflow.com/questions/67879442/borrowed-value-does-not-live-enough – rollingBalls Jun 07 '21 at 22:43
5

The first error in your error message is that Sync is not implemented for RefCell<String>. This is by design, as stated by Sync's rustdoc:

Types that are not Sync are those that have “interior mutability” in a non-thread-safe form, such as Cell and RefCell. These types allow for mutation of their contents even through an immutable, shared reference. For example the set method on Cell takes &self, so it requires only a shared reference &Cell. The method performs no synchronization, thus Cell cannot be Sync.

Thus it's not safe to share RefCells between threads, because you can cause a data race through a regular, shared reference.

But what if you wrap it in Arc ? Well, the rustdoc is quite clear again:

Arc will implement Send and Sync as long as the T implements Send and Sync. Why can’t you put a non-thread-safe type T in an Arc to make it thread-safe? This may be a bit counter-intuitive at first: after all, isn’t the point of Arc thread safety? The key is this: Arc makes it thread safe to have multiple ownership of the same data, but it doesn’t add thread safety to its data. Consider Arc<RefCell>. RefCell isn’t Sync, and if Arc was always Send, Arc<RefCell> would be as well. But then we’d have a problem: RefCell is not thread safe; it keeps track of the borrowing count using non-atomic operations.

In the end, this means that you may need to pair Arc with some sort of std::sync type, usually Mutex.

Arc<T> will not be Sync unless T is Sync because of the same reason. Given that, probably you should use std/tokio Mutex instead of RefCell

Svetlin Zarev
  • 14,713
  • 4
  • 53
  • 82
  • Thank you very much for the detailed explanation! This makes much more sense to me now. I tried with a Mutex and it goes one step further but there's a different error. I made a follow up Q here if you'd like to take a look: https://stackoverflow.com/questions/67879442/borrowed-value-does-not-live-enough – rollingBalls Jun 07 '21 at 22:46