5 ms·
async fn do_health_check_par<HC>(hc: HC) where HC: HealthCheck + Send + 'static, HC::check(): Send, // <-- associated return type { tokio::task::spa
by qaq 3y ago
async fn do_health_check_par<HC>(hc: HC)
where
HC: HealthCheck + Send + 'static,
HC::check(): Send, // <-- associated return type
{
tokio::task::spawn(async move {
if !hc.check().await {
log_health_check_failure().await;
}
});
}
Hmm I think for 95% of the people sticking to something like Swift would work out better for them
- hgomersall 3y agoAre you saying 95% of use cases require spawning new tasks within the trait implementation based on argument futures? Or are you making a more general comment about rust generics? The MVP looks about as clean as I could hope for most use cases.
- qaq 3y agoI am saying that in web services you will frequently use async functions that look like async fn do_blah(db_repo: impl DBRepo ...) {...} and are executed on async-std or Tokio
- hgomersall 3y agoThat will work. It only needs the additional bounds if you want to spawn that as a new task.
- qaq 3y agoso if I am doing async calls on DBRepo inside that function they can not be moved to a different thread by a runtime like tokio?
- jen20 3y agoOne would typically not spawn those - as I understand it you need the type constraints if calling “tokio::spawn” (or some equivalent) but not if simply calling an async function in the same task.