Using RwLock in a Json

[Compro-Prasad]

I have the following handler function which works:

async fn axum_handler(State(state): State<Arc<RwLock<Vec<i32>>>>) -> impl IntoResponse {
    let lock = state.clone();
    let val = lock.read().unwrap();
    return Json(val.clone());
}

Pro: Simple enough to implement
Con: val.clone() clones the vector

Here I am returning Json(val.clone()) which I want to avoid as it might be a performance issue. So, I tried the following two methods:

Alternative 1

async fn axum_handler(State(state): State<Arc<RwLock<Vec<i32>>>>) -> impl IntoResponse {
    let lock = state.clone();
    let val = lock.read().unwrap();
    let serialized_data = serde_json::to_string(&*val).unwrap();
    let mut headers = HeaderMap::new();
    headers.insert("content-type", "application/json".parse().unwrap());
    return (headers, serialized_data);
}

Pro: No clone required
Con: Lot of non-axum code as I can't directly use Json(&*val)

Alternative 2

async fn axum_handler(State(state): State<Arc<RwLock<Arc<Vec<i32>>>>>) -> impl IntoResponse {
    let lock = state.clone();
    let val = lock.read().unwrap().clone();
    let val = Arc::into_inner(val).unwrap();
    return Json(val);
}

Pro: Simple enough as an alternative
Con: The state requires bit more memory and the type is too big

What I want

An alternative that uses a very basic state with preferably no copies when returning it in a Json.

[davidpdrsn]

You can use https://docs.rs/axum-extra/0.7.5/axum_extra/response/struct.ErasedJson.html

You can also always make your own type that implements IntoResponse

[Compro-Prasad]

Thanks @davidpdrsn . I am using ErasedJson now. The code is as follows:

async fn axum_handler(State(state): State<Arc<RwLock<Vec<i32>>>>) -> impl IntoResponse {
    let lock = state.clone();
    let val = lock.read().unwrap();
    return ErasedJson::new(&*val);
}

Any reason why ErasedJson is not the same as Json? I mean what are the pros and cons of each?

[davidpdrsn]

ErasedJson can’t be an extractor and just having one type for the response and extractor is nice I think.

But one is not more “correct” than the other. Just different ways of doing the same thing.