Support for passing async fn into advertise_service

[entire]

In the service_server.rs example, I've noticed that there is:

    let _handle = client
        .advertise_service::<std_srvs::SetBool>("/my_set_bool", my_service)
        .await?;

and my_service is a simple fn here, but many services are often going to require async/await type functions to run within the function. Is there plan to support async fn here?

If not, I'm happy to look into creating a PR to add support for this especially because I'd like to use async functions within my service callback that I pass in.

[ssnover]

If you're blocked on this you still have the option of calling tokio::spawn here.

[Carter12s]

I think it is definitely something we'd like to support if possible. It shouldn't be too hard to try experimenting with our internal type erasure to see if this works, but I'm suspicious we're going to hit some limitation of async fn in rust that might require a more significant overhaul. If you'd like to dig on on PR trying to implement it @entire that would be awesome. If not, I'll probably take a look at it in the next week or so.

[entire]

@ssnover agreed - i think it would just be nicer overall though for the functions to be async in general though.

@Carter12s - thanks, makes sense. let me take a look at it and I'll take a stab at it if it seems relatively not difficult.

[ssnover]

Having glanced at this for a bit, the main challenge is our paradigm around type erasure with the closure. Async closures are unstable, which means the message: &str parameter will have to find another way in.

If you look at implementing this: I'd recommend tokio::spawn with a channel. Wrap the tokio::JoinHandle in an abort_on_drop::ChildTask and add that to the struct that gets store in the services map along with the sender side of the channel for messages.

[Carter12s]

Update!

Async closures have merged! rust-lang/rust#132706

We should be able to build this out once the next version of rust ships (could build it out on nightly right now).

Once built we can put it behind a feature flag to not affect out min rust version too much. But super excited this is coming.

[Carter12s]

Rust 1.85 is officially out with async closures are fully supported!!!

We're ready to start work on this one.

[ssnover]

Do we have an established MSRV target? It's pretty common for the ecosystem to support current stable and the two previous versions.

[Carter12s]

README currently calls out 1.75, but I don't think we've got that in the Cargo.tomls yet.

My thought here is that we build this feature out under a feature flag ["async-closures"], and when ~1.87 drops we enable that feature as default.

I'm open to opinions on the API, but it feels like it is worth keeping the non-async versions around? Have both advertise_service and advertise_async_service? That makes the change non-breaking, additive, and pretty clean behind a feature flag.