starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #569] Switch all usage of tokio::spawn/executor to be generic over futures::Executor #539

New issue

Open

opened 2026-03-15 23:01:03 +03:00 by kerem · 8 comments

kerem commented

2026-03-15 23:01:03 +03:00

Owner

Originally created by @bluejekyll on GitHub (Oct 5, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/569

This should make the libraries less dependent on Tokio and allow other Executors to be used.

Originally created by @bluejekyll on GitHub (Oct 5, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/569 This should make the libraries less dependent on Tokio and allow other Executors to be used.

kerem added the

cleanup

crate:resolver

labels

2026-03-15 23:01:03 +03:00

kerem commented

2026-03-15 23:01:14 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 5, 2018):

This is in response to feedback on #566 and @hawkw

@bluejekyll commented on GitHub (Oct 5, 2018): This is in response to feedback on #566 and @hawkw

kerem commented

2026-03-15 23:01:19 +03:00

Author

Owner

@hawkw commented on GitHub (Oct 5, 2018):

I mentioned this in https://github.com/bluejekyll/trust-dns/pull/566#discussion_r222824992, but I'm repeating it here for the sake of anyone else reading this issue:

While being generic over executors and being less directly coupled to tokio has many benefits, there is the potential drawback of increased API complexity. In particular, users of the resolver would have to know what executor they're using, and thread that type through as as additional generic parameter. Many constructors would need to take an additional executor parameter as well.

For people using trust-dns-resolver with tokio, which I suspect describes a vast majority of downstream users, the executor type would almost always end up being DefaultExecutor, and the extra parameter DefaultExecutor::current(), so this could add a lot of ceremony to their code without offering them any real benefit.

It might be worth determining how much interest there is in using trust-dns-resolver with non-tokio executors (such as the deprecated tokio-core), before deciding whether or not this is a good choice?

@hawkw commented on GitHub (Oct 5, 2018): I mentioned this in https://github.com/bluejekyll/trust-dns/pull/566#discussion_r222824992, but I'm repeating it here for the sake of anyone else reading this issue: While being generic over executors and being less directly coupled to `tokio` has many benefits, there is the potential drawback of increased API complexity. In particular, users of the resolver would have to know what executor they're using, and thread that type through as as additional generic parameter. Many constructors would need to take an additional executor parameter as well. For people using `trust-dns-resolver` with `tokio`, which I suspect describes a vast majority of downstream users, the executor type would almost always end up being `DefaultExecutor`, and the extra parameter `DefaultExecutor::current()`, so this could add a lot of ceremony to their code without offering them any real benefit. It might be worth determining how much interest there is in using `trust-dns-resolver` with non-`tokio` executors (such as the deprecated `tokio-core`), before deciding whether or not this is a good choice?

kerem commented

2026-03-15 23:01:24 +03:00

Author

Owner

@cramertj commented on GitHub (Oct 26, 2018):

I would also love this and would be interested in helping contribute. I'd like to use trust-dns on Fuchsia, where we use a custom (non-tokio) executor. As @hawkw says, this might result in some increased API complexity, but perhaps this could be mitigated via an optional dependency on tokio, similar to the one that hyper uses in its default APIs?

@cramertj commented on GitHub (Oct 26, 2018): I would also love this and would be interested in helping contribute. I'd like to use trust-dns on Fuchsia, where we use a custom (non-tokio) executor. As @hawkw says, this might result in some increased API complexity, but perhaps this could be mitigated via an optional dependency on tokio, similar to the one that hyper uses in its default APIs?

kerem commented

2026-03-15 23:01:30 +03:00

Author

Owner

@tkilbourn commented on GitHub (Oct 26, 2018):

trust-dns could still have a crate that uses tokio since that's the most popular executor, but abstracting over generic executors makes it possible for other platforms as well.

@tkilbourn commented on GitHub (Oct 26, 2018): `trust-dns` could still have a crate that uses `tokio` since that's the most popular executor, but abstracting over generic executors makes it possible for other platforms as well.

kerem commented

2026-03-15 23:01:35 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 26, 2018):

I think this would be very cool as well. I do want to point out that other tokio pieces are in use around the library. For example, the tokio-io, tokio-tcp, tokio-udp and tokio-timer crates. I want to make sure that we're only talking about the tokio-reactor and tokio-executor, and not all the tokio pieces.

this could be mitigated via an optional dependency on tokio, similar to the one that hyper uses in its default APIs?

I like this idea. Perhaps we can default the type parameters when tokio-executor feature is enabled (maybe this is what you meant)?

trust-dns could still have a crate that uses tokio since that's the most popular executor, but abstracting over generic executors makes it possible for other platforms as well.

Agreed, not sure if a separate crate is needed or not, so we can handle that as it comes up.

The only other concern I have is testing, as we won't easily have a way of testing other executors. Not sure if you have any ideas here.

@bluejekyll commented on GitHub (Oct 26, 2018): I think this would be very cool as well. I do want to point out that other tokio pieces are in use around the library. For example, the tokio-io, tokio-tcp, tokio-udp and tokio-timer crates. I want to make sure that we're only talking about the tokio-reactor and tokio-executor, and not all the tokio pieces. > this could be mitigated via an optional dependency on tokio, similar to the one that hyper uses in its default APIs? I like this idea. Perhaps we can default the type parameters when tokio-executor feature is enabled (maybe this is what you meant)? > trust-dns could still have a crate that uses tokio since that's the most popular executor, but abstracting over generic executors makes it possible for other platforms as well. Agreed, not sure if a separate crate is needed or not, so we can handle that as it comes up. The only other concern I have is testing, as we won't easily have a way of testing other executors. Not sure if you have any ideas here.

kerem commented

2026-03-15 23:01:40 +03:00

Author

Owner

@tkilbourn commented on GitHub (Oct 26, 2018):

Ideally the Rust async ecosystem finds similar ways to abstract over io, tcp, udp, timers, etc, but I understand that's potentially a longer-term vision that might not come to fruition immediately.

If Fuchsia ends up with a dependency on trust-dns, we'll find a way to work out a testing strategy that works. In the short term we could take the responsibility of testing and patching each time we roll trust-dns forward in our own repo.

@tkilbourn commented on GitHub (Oct 26, 2018): Ideally the Rust async ecosystem finds similar ways to abstract over io, tcp, udp, timers, etc, but I understand that's potentially a longer-term vision that might not come to fruition immediately. If Fuchsia ends up with a dependency on trust-dns, we'll find a way to work out a testing strategy that works. In the short term we could take the responsibility of testing and patching each time we roll trust-dns forward in our own repo.

kerem commented

2026-03-15 23:01:45 +03:00

Author

Owner

@cramertj commented on GitHub (Oct 26, 2018):

On a case-by-case basis:

tokio-io isn't dependent on anything else from the tokio ecosystem, and has been rebranded and exposed as futures-io in 0.3, with compatibility functionality between the two. This is fine.
tokio-tcp: Hyper solves this with the Connect trait, which we already implement so that we can use Hyper. Perhaps this would work here as well?
tokio-udp: I'm not aware of an existing trait for this, but AFAICT we just need: create from SocketAddr, poll_send_to, poll_read_from, and a few other various setters.
tokio-timer: Similar-- add a trait which can create a future which resolves after a deadline.

@cramertj commented on GitHub (Oct 26, 2018): On a case-by-case basis: - `tokio-io` isn't dependent on anything else from the tokio ecosystem, and has been rebranded and exposed as `futures-io` in 0.3, with compatibility functionality between the two. This is fine. - `tokio-tcp`: Hyper solves this with the [Connect](https://docs.rs/hyper/0.12.13/hyper/client/connect/trait.Connect.html) trait, which we already implement so that we can use Hyper. Perhaps this would work here as well? - `tokio-udp`: I'm not aware of an existing trait for this, but AFAICT we just need: create from `SocketAddr`, `poll_send_to`, `poll_read_from`, and a few other various setters. - `tokio-timer`: Similar-- add a trait which can create a future which resolves after a deadline.

kerem commented

2026-03-15 23:01:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 26, 2018):

These are going to require a bunch of refactorings. We're probably going to end up reevaluating some of my past decisions on some traits, etc, and most likely will want to simplify some of those as well, especially around the TCP and UDP (and other) interfaces.

I've been working through some of this recently, there are some types that can go away, and others that are probably unnecessary. Don't hesitate to ask me questions as you run into some of these things...

@bluejekyll commented on GitHub (Oct 26, 2018): These are going to require a bunch of refactorings. We're probably going to end up reevaluating some of my past decisions on some traits, etc, and most likely will want to simplify some of those as well, especially around the TCP and UDP (and other) interfaces. I've been working through some of this recently, there are some types that can go away, and others that are probably unnecessary. Don't hesitate to ask me questions as you run into some of these things...