Why application state is always wrapped in an Arc pointer?

[bandrefilipe]

The documentation introduces us about the application state, and how we can (a) share it between worker threads or (b) not.

a. To share state between worker threads we create the web::Data instance outside the HttpServer::new closure:

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Note: web::Data created outside the closure
    let state = web::Data::new("some state");

    HttpServer::new(move || {
        // move state into the closure
        App::new()
            .app_data(state.clone()) // <- register the created data
            .default_service(web::to(handler))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

This way, all worker threads share the same single state instance through an Arc smart pointer (which is necessary).

b. If we don't want to share state between worker threads, so each worker thread has its own instance of state, we need only to create the web::Data instance inside the HttpServer::new closure:

#[actix_web::main]
async fn main() -> std::io::Result<()> {

    HttpServer::new(|| {
        App::new()
            .app_data(web::Data::new("some state")) // <- Note: web::Data created inside the closure
            .default_service(web::to(handler))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

This way, each worker thread has a distinct state instance, but also through an Arc smart pointer.

Question: is it necessary the use of an Arc pointer in b's example? And if not, can we avoid the little overhead of an Arc through the use of a simple Rc?

[robjtede]

The most common use case for Data is to create shared state which is why it works this way; it is a safe default.

Alternatives for b):

• LocalData from actix-web-lab
  • uses an Rc internally
• .app_data("some state") + req.app_data::<&'static str>() where async fn handler(req: HttpRequest) { ...
  • pro: skips the extra boxed pointers entirely
  • con: potentially requires more boilerplate in handlers

[bandrefilipe]

Thank you for the quick response!
The .app_data("some state") was just a lazy example, but it's nice to know there are ways around it.

[fakeshadow]

a. No you don't share anything that you move in to the HttpServer::new() closure. Everything inside is thread local and are not moved between threads unless you explicit call it from middleware or handler function. You get a sense of sharing state because of the Arc smart pointer where multiple instances of Arc can be used to deref to the inner T.

b. This is the same thing as point a but it's more obvious since you are already inside the closure.

answer to your question:
Yes Arc is necessary.

1. The data can be used across thread boundary.(If the T is able to.) Imagine you use Rc<T> with apis like tokio::spawn and tokio::task::spawn_blocking etc. Third party crates also mostly default to apis with fn call(arg) -> impl Future + Send.
2. It's a performance booster with large scale of application. Because like the point a pointed out everything inside closure is thread local so a local Arc have no contention at all. Which means you pay for an extra layer of indirection with Arc<Arc<T>> in exchange for contention free atomic operation.