lookup_host result can't be send across threads safely

[nlnetlabs]

lookup_host result can't be send across threads safely

[kaoet]

Can we change the Resolver trait to use https://docs.rs/async_trait?

[glts]

I’m wondering if Resolver::Query should perhaps be Send? I am also running into a situation where it seems to me a Send future there would make the trait more generally usable?

For example, here is another program that would compile if Resolver::Query were Send:

use async_trait::async_trait;
use domain::resolv::StubResolver;
use std::net::IpAddr;

#[async_trait]
trait Lookup {
    async fn lookup_ptrs(&self, ip: IpAddr) -> Vec<String>;
}

struct Resolver {
    delegate: StubResolver,
}

#[async_trait]
impl Lookup for Resolver {
    async fn lookup_ptrs(&self, ip: IpAddr) -> Vec<String> {
        self.delegate
            .lookup_addr(ip)
            .await
            .unwrap()
            .into_iter()
            .map(|p| p.to_string())
            .collect()
    }
}

#[tokio::main]
async fn main() {
    let resolver = Resolver {
        delegate: StubResolver::new(),
    };

    let addrs = resolver.lookup_ptrs(IpAddr::from([8, 8, 8, 8])).await;

    println!("{:?}", addrs);
}

[partim]

Apologies for the ridiculously late answer!

Requiring Resolver::Query to be Send + 'static is a good idea, indeed. It should be easy to achieve this for stub::Query by placing the data of a StubResolver behind an arc and keep that in Query.

I’ll draft a PR for it and see if it really is all that simple.

[partim]

Can we change the Resolver trait to use https://docs.rs/async_trait?

The trait is already what I imagine async trait would turn it into. Resolver::query is basically an async function in anything but the name. It returns a future which you can await.

[partim]

Turns out that resolv::stub::Query is already Send, so requiring the trait in Resolver::Query is enough.

However, I now wonder if it might be worthwhile to turn this whole concept on its head by making the lookups implement a trait and ditch the Resolver trait. I think the lookups can be made in such a way that they don’t need to be aware of how the underlying querying mechanism works and whether it is synchronous or asynchronous atop Tokio or async-std or something else entirely.