[GH-ISSUE #430] `ResolverFuture::lookup_ip()` is not lazy (enough) #486

New issue

Closed

opened 2026-03-15 22:45:17 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 22:45:17 +03:00

Owner

Originally created by @briansmith on GitHub (Apr 26, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/430

Futures shouldn't do any work until polled, so that they can support code patterns like this (taken from real code):

        // Construct the future, expecting nothing will happen yet.
        let lookup = self.resolver.lookup_ip(&name.0);

        // Do something that needs to be done before the lookup
        // is initiated.
        let f = Timeout::new(delay, &self.executor)
            .expect("Timeout::new() won't fail")
            .then(move |_| {
                // OK, now actually start doing the lookup work.
                lookup
            });

        // Wrap the future in a Box, giving it a lifetime that is (potentially)
        // longer than `self`. Because of this lifetime issue, we can't call
        // `self.resolver.lookup_ip(&name.0);` inside the closure above.
        return Box::new(f);

ResolverFuture::lookup_ip() appears to be doing a lot of work and so it doesn't seem to support this code pattern well.

Originally created by @briansmith on GitHub (Apr 26, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/430 Futures shouldn't do any work until polled, so that they can support code patterns like this (taken from real code): ```rust // Construct the future, expecting nothing will happen yet. let lookup = self.resolver.lookup_ip(&name.0); // Do something that needs to be done before the lookup // is initiated. let f = Timeout::new(delay, &self.executor) .expect("Timeout::new() won't fail") .then(move |_| { // OK, now actually start doing the lookup work. lookup }); // Wrap the future in a Box, giving it a lifetime that is (potentially) // longer than `self`. Because of this lifetime issue, we can't call // `self.resolver.lookup_ip(&name.0);` inside the closure above. return Box::new(f); ``` `ResolverFuture::lookup_ip()` appears to be doing a lot of work and so it doesn't seem to support this code pattern well.

kerem

2026-03-15 22:45:17 +03:00

closed this issue
added the
crate:all

cleanup
labels

kerem commented

2026-03-15 22:45:33 +03:00

Author

Owner

@hawkw commented on GitHub (May 18, 2018):

I'd like to start looking into this issue --- @bluejekyll, are you actively working on this and/or will it interfere with any other ongoing work?

@hawkw commented on GitHub (May 18, 2018): I'd like to start looking into this issue --- @bluejekyll, are you actively working on this and/or will it interfere with any other ongoing work?

kerem commented

2026-03-15 22:45:39 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 18, 2018):

I'm not aware of this effecting any other work, and no, I haven't started working on it. I will warn you, I don't know yet how deep this goes... but it could unravel quickly, especially in how timeouts are tracked.

@bluejekyll commented on GitHub (May 18, 2018): I'm not aware of this effecting any other work, and no, I haven't started working on it. I will warn you, I don't know yet how deep this goes... but it could unravel quickly, especially in how timeouts are tracked.

kerem commented

2026-03-15 22:45:44 +03:00

Author

Owner

@hawkw commented on GitHub (May 18, 2018):

Well, I have a preliminary branch making this change. It's rather ugly, so probably needs some more work on my end before it's ready for a PR...

@hawkw commented on GitHub (May 18, 2018): Well, I have [a preliminary branch](https://github.com/bluejekyll/trust-dns/compare/master...hawkw:eliza/lazier-resolver-future?expand=1) making this change. It's rather ugly, so probably needs some more work on my end before it's ready for a PR...

kerem referenced this issue

2026-03-15 22:49:38 +03:00

[GH-ISSUE #486] Ensure Resolver functions currectly with cache size 0 #500