starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #926] Async_std support #568

New issue

Closed

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

kerem commented

2026-03-15 23:11:56 +03:00

Owner

Originally created by @Softsapiens on GitHub (Nov 20, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/926

Hi all!
I would like to know if there is any option to decouple trust-dns-resolver from tokio in order to use async_std as executor runtime, or at least, if there are plans for making easy that integration, perhaps using trust-dns-client ClientFuture.

I have tried to use the AsyncResolver spwaned on async_std::task but I get the same situation as is https://github.com/bluejekyll/trust-dns/issues/905

Thanks an advance, and thanks for such a great library.

Originally created by @Softsapiens on GitHub (Nov 20, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/926 Hi all! I would like to know if there is any option to decouple trust-dns-resolver from tokio in order to use async_std as executor runtime, or at least, if there are plans for making easy that integration, perhaps using trust-dns-client ClientFuture. I have tried to use the AsyncResolver spwaned on async_std::task but I get the same situation as is https://github.com/bluejekyll/trust-dns/issues/905 Thanks an advance, and thanks for such a great library.

kerem

2026-03-15 23:11:56 +03:00

closed this issue
added the
enhance

crate:proto

crate:resolver
labels

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Nov 20, 2019):

Currently this is not being worked on, though it is something that we could work towards. #913 removes all background spawns from the Resolver (I'm working on the last few changes there).

No, don't just use the ClientFuture, as that is not a Resolver, and won't serve those needs properly.

After #913, there will need to be a lot of additional work to allow for alternative async-std UDP, TCP, TLS, and HTTPS implementations to be supported. All of this is of course possible, but that will require a bunch of investigation. There are many good reasons to do this work, beyond supporting async-std, which include making the library more usable on new operating systems and such. So this is definitely something we should do.

@bluejekyll commented on GitHub (Nov 20, 2019): Currently this is not being worked on, though it is something that we could work towards. #913 removes all background spawns from the Resolver (I'm working on the last few changes there). No, don't just use the ClientFuture, as that is not a Resolver, and won't serve those needs properly. After #913, there will need to be a lot of additional work to allow for alternative `async-std` UDP, TCP, TLS, and HTTPS implementations to be supported. All of this is of course possible, but that will require a bunch of investigation. There are many good reasons to do this work, beyond supporting `async-std`, which include making the library more usable on new operating systems and such. So this is definitely something we should do.

kerem commented

2026-03-15 23:12:17 +03:00

Author

Owner

@Softsapiens commented on GitHub (Nov 21, 2019):

Thanks

@Softsapiens commented on GitHub (Nov 21, 2019): Thanks

kerem commented

2026-03-15 23:12:22 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 21, 2019):

We can leave this issue open as a tracking issue, and discussion.

@bluejekyll commented on GitHub (Nov 21, 2019): We can leave this issue open as a tracking issue, and discussion.

kerem commented

2026-03-15 23:12:27 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 12, 2019):

FYI, with #935 landed, this is something we could start work on.

@bluejekyll commented on GitHub (Dec 12, 2019): FYI, with #935 landed, this is something we could start work on.

kerem commented

2026-03-15 23:12:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 15, 2019):

I'm not sure if we can do this (easily) before AsyncRead and AsyncWrite are common between Futures, Tokio and async-std. But the work I believe is basically implementing a new ConnectionProvider for async-std:

github.com/bluejekyll/trust-dns@4e91786388/crates/resolver/src/name_server/connection_provider.rs (L46-L56)

@bluejekyll commented on GitHub (Dec 15, 2019): I'm not sure if we can do this (easily) before AsyncRead and AsyncWrite are common between Futures, Tokio and async-std. But the work I believe is basically implementing a new ConnectionProvider for async-std: https://github.com/bluejekyll/trust-dns/blob/4e917863888bf2b371bff191ffe91a946e7b60fc/crates/resolver/src/name_server/connection_provider.rs#L46-L56

kerem commented

2026-03-15 23:12:37 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 28, 2019):

With #975 done, I think this should be fairly straight forward at this point.

@bluejekyll commented on GitHub (Dec 28, 2019): With #975 done, I think this should be fairly straight forward at this point.

kerem commented

2026-03-15 23:12:42 +03:00

Author

Owner

@belak commented on GitHub (Mar 25, 2020):

I believe this will also require changes in the lower level libraries for the different TLS implementations as well.

@belak commented on GitHub (Mar 25, 2020): I believe this will also require changes in the lower level libraries for the different TLS implementations as well.

kerem commented

2026-03-15 23:12:48 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 26, 2020):

Most likely. But that doesn’t need to be part of an MVP.

@bluejekyll commented on GitHub (Mar 26, 2020): Most likely. But that doesn’t need to be part of an MVP.

kerem referenced this issue

2026-03-16 02:10:50 +03:00

[PR #568] [MERGED] Fix multithreaded example #1518