Using lock().unwrap().as_mut() instead of interact() to avoid using static lifetime for a &str

[peter-scholtens]

For a function print_async to accept an &str I have to set the lifetime to 'static when using interact(). However, as the function awaits for the execution, I wonder if that can be avoided. I'm aware that this can be solved with Arc, but I want to avoid defining Arc's on every (sub)field of my data structure. Instead I rewrote the function to avoid starting a new thread using the lock().unwrap().as_mut() to force execution before returning.

Following the example in the deadpool / diesel directory, with interact.rs:

use deadpool_diesel::sqlite::{Manager, Pool, Runtime};
use diesel::{prelude::*, select, sql_types::Text};

async fn print_async(pool: &Pool, message: &'static str) {
    let conn = pool.get().await.unwrap();
    let result = conn
        .interact(move |conn| {
            let query = select(message.clone().into_sql::<Text>());
            query.get_result::<String>(conn)
        })
        .await;
    println!("{:?}", result.unwrap().unwrap());
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let manager = Manager::new(":memory:", Runtime::Tokio1);
    let pool = Pool::builder(manager).max_size(8).build().unwrap();
    let future1 = print_async(&pool, "Hello World!");
    let future2 = print_async(&pool, "Good bye!");
    tokio::join!(future1, future2);
    Ok(())
}

And without the additional thread, lock.rs:

use deadpool_diesel::sqlite::{Manager, Pool, Runtime};
use diesel::{prelude::*, select, sql_types::Text};

async fn print_async(pool: &Pool, message: &str) {
    let conn = pool.get().await.unwrap();
    let query = select(message.into_sql::<Text>());
    let result = query
        .get_result::<String>(conn.lock().unwrap().as_mut())
        .unwrap();
    println!("{:?}", result);
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let manager = Manager::new(":memory:", Runtime::Tokio1);
    let pool = Pool::builder(manager).max_size(8).build().unwrap();
    let future1 = print_async(&pool, "Hello World!");
    let future2 = print_async(&pool, "Good bye!");
    tokio::join!(future1, future2);
    Ok(())
}

I have two questions:

1. What are the con's of the approach in above placed example lock.rs?
2. Given the restriction of 'static, wouldn't it be nice to have an example using lock().unwrap().as_mut(), or a re-write as fn immediate(), too?

[bikeshedder]

Without the worker you (can) end up blocking you entire async reactor.

You might not run into any problems as some runtimes try to detect this kind of usage and spawn a new thread under the hood in order to prevent this kind of situation. This is however by no means "good practice" and you are better of spawning a thread yourself. That's essentially what interact() does for you. It forces you to do it correctly.

You're of course free to call spawn_blocking directly and wrap the code that way. interact() is just a convenience wrapper which makes this simpler.

btw. spawning threads is (usually) very cheap and runtimes make that even cheaper by implementing a thread pool under the hood. So repeated calls to spawn_blocking might end up reusing the same thread over and over again.

[peter-scholtens]

I don't understand how calling spawn_blocking will make a difference as interact() already calls this. It looks to me that the borrow checker does not interpret the await or join! and sees a lifetime problem ( 'message' escapes the function body here argument requires that '1 must outlive 'static ), even after the value is consumed. My application function looks like this:

async fn print_all(pool: &Pool, message1: &str,message2: &str) {
    let future1 = print_async(&pool, message1);
    let future2 = print_async(&pool, message2);
    tokio::join!(future1, future2);
}

But that will not work either then. So that means I need to either copy the str or put Arc<Mutex> on every detail of a structure...?

[bikeshedder]

I don't understand how calling spawn_blocking will make a difference as interact() already calls this.

It doesn't make a difference.

That's exactly what I meant by "convenience wrapper which makes this simpler".

But that will not work either then. So that means I need to either copy the str or put Arc on every detail of a structure...?

How about moving the data in and out instead? As long as your data structure implements Move you should be safe. So instead of str you can use a String or for a slightly better memory efficiency Box<str> works, too.

[peter-scholtens]

If rewritten the file lock.rs from above to use the locally created Box, and I get exactly the same error: 'message' escapes the function body...

use deadpool_diesel::sqlite::{Manager, Pool, Runtime};
use diesel::result::Error;

use diesel::{prelude::*, select, sql_types::Text};
use std::sync::Arc;

async fn print_async<'a>(pool: &Pool, message: &'a str) -> (Box<&'a str>, Result<String, Error>) {
    let conn = pool.get().await.unwrap();
    let message = Box::new(message);
    let result = conn
        .interact(move |conn| {
            let query = select((*message).into_sql::<Text>());
            (message, query.get_result::<String>(conn))
        })
        .await;
    result.unwrap()
}

async fn print_all(pool: &Pool, message1: &str, message2: &str) {
    let future1 = print_async(&pool, message1);
    let future2 = print_async(&pool, message2);
    tokio::join!(future1, future2);
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let manager = Manager::new(":memory:", Runtime::Tokio1);
    let pool = Pool::builder(manager).max_size(8).build().unwrap();
    print_all(&pool, "Hello World", "Goodbye");
    Ok(())
}

[bikeshedder]

You need to use a Box<str>, not a Box<&str>. If that gives you any headaches just use a String. The performance difference is negligible.

[bikeshedder]

Here is an interesting video outlining the differences: https://youtu.be/A4cKi7PTJSs?si=8GtlXMPJW1_sbG3C&t=874

Personally I usually stick to just using a String unless I'm extremely worried about memory size.

[peter-scholtens]

Indeed with Box it works. Thinking about the pointers I realized I could better clone the Arc> of the larger struct, and dive into the field at the closure: then I only hand over a pointer and don't need to copy things (from non-static data).