mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 11:15:54 +03:00
[GH-ISSUE #1250] Upgrade to tokio v0.3 #633
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#633
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zonyitoo on GitHub (Oct 16, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1250
Tokio v0.3 have been released: https://tokio.rs/blog/2020-10-tokio-0-3
@bluejekyll commented on GitHub (Oct 16, 2020):
Not clear what work there is here right now.
@zonyitoo commented on GitHub (Oct 16, 2020):
At lease the following works have to be done: :P
AsyncRead::poll_readruntime::Handleis no longer public@djc commented on GitHub (Oct 16, 2020):
For now, this is blocked on new tokio-rustls, tokio-tls and tokio-openssl releases.
@bluejekyll commented on GitHub (Oct 16, 2020):
Handle is no longer public? Hm. I must have missed that in the Tokio dev messages.
I’m a fan of handle specifically to know when a runtime has actually been instantiated in a typesafe way.
@djc commented on GitHub (Oct 17, 2020):
It looks like tokio-tls is no longer being maintained and new development happens in tokio-native-tls (see #1251). It looks like all of tokio-rustls, tokio-native-tls and tokio-openssl now have tokio 0.3-compatible releases.
@bluejekyll can we assume that the next trust-dns release will be tokio 0.3 only?
@bluejekyll commented on GitHub (Oct 17, 2020):
yes. I think so.
@zonyitoo commented on GitHub (Nov 3, 2020):
Hello, what's the status of migrating to tokio v0.3? @bluejekyll
@bluejekyll commented on GitHub (Nov 3, 2020):
#1262 Not looking good right now.
@LEXUGE commented on GitHub (Nov 3, 2020):
If you are on hurry of migrating to tokio v0.3, you could probably adopt tokio-compat first. I tested that out and it works fine with trust-dns-resolver.
@bluejekyll commented on GitHub (Nov 3, 2020):
Would you mind posting an example?
@LEXUGE commented on GitHub (Nov 4, 2020):
github.com/LEXUGE/dcompass@4da162b756/dcompass/src/filter.rs (L84)Like above, add
use tokio_compat_02::FutureExt;and use.compat()before.awaitwhenever necessary. That helps me to use tokio v0.3 features with trust-dns v0.19.5.P.S. unrelated, but I am getting trouble with performance in implementing a DNS "forwarder". It seems like it is underperformed and I doubt whether resolver is the right crate for it because it is too "high-level". Maybe
clientis the right crate, but it lacks easy-to-spot DoH and DoT features (seemsStreams are in separate crates). Isclientthe right one?@MikailBag commented on GitHub (Nov 6, 2020):
Let me note that tokio-compat-02 uses single-thread runtime. It means all tasks spawned using tokio 02 APIs will not benefit from multiple CPU cores. Maybe it's the reason of performance problem.