FuturesResolver need to be kept around for at least the lifetime of the Future

[azdlowry]

I'm not sure if this is actually an issue or my misunderstanding of the intention. Modifying the futures.rs example with the following main function:

fn main() {
    // Create Resolver and make a query.
    let query = {
        let resolver = FutureResolver::new().expect("Failed to create resolver");
        resolver.query_mx("gmail.com").then(|result| {
            print_mx_results(&result);
            result
        })
    };

    // Run the query to completion and print the results.
    let mut event_loop = tokio_core::reactor::Core::new().expect("Failed to create event loop");
    event_loop.run(query).ok();
}

This will always fail because FutureResolver is dropped before the the query is executed on the reactor.

The examples work fine, however in practise DNS lookup is just the first step of a larger operation and it can be difficult to code such that the FutureResolver is kept around long enough. It may be possible to put it in a lazy static, I'm not certain what is the affect of keeping the FutureResolver around for ever. (Especially in circumstances where the network might change)

[dimbleby]

This is as designed, but I understand that it's not entirely intuitive and perhaps even unhelpful.

I think I see a way to keep things alive while queries are pending, but I must admit that I'm in two minds about whether this is always the desired behaviour - I've become accustomed to things as they are!

Probably the code that you want to write above is completely reasonable, but it might take me a little while to reflect and convince myself of that; and then also a little while to implement it...

[azdlowry]

I usually write Futures so that the they consume everything it needs to complete, then the future itself controls the lifetime. This is how I've worked around the issue, by wrapping the Future returned from resolver.query_a in another Future that consumes the FutureResolver.

[dimbleby]

Sure, my proposed mechanism is somewhat similar. I've pushed a sketch of the idea here, where the trickiness is happening in query_mx() (and would have to be repeated in all the other places).

But I want to think about this for a bit before committing to it!