Make the stub resolver shareable. #175
Comments
WhyNotHugo
added a commit
to WhyNotHugo/domain
that referenced
this issue
Sep 16, 2024
This somewhat simplifies usage for call sites. They no longer need to use `&&StubResolver` for some APIs, and a future can be handed off without being tied to the lifetime of the resolver. The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data. This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release. Fixes: NLnetLabs#175
WhyNotHugo
added a commit
to WhyNotHugo/domain
that referenced
this issue
Sep 16, 2024
This somewhat simplifies usage for call sites. They no longer need to use `&&StubResolver` for some APIs, and a future can be handed off without being tied to the lifetime of the resolver. The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data. This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release. Fixes: NLnetLabs#175
WhyNotHugo
added a commit
to WhyNotHugo/domain
that referenced
this issue
Sep 16, 2024
This somewhat simplifies usage for call sites. They no longer need to use `&&StubResolver` for some APIs, and a future can be handed off without being tied to the lifetime of the resolver. The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data. This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release. Fixes: NLnetLabs#175
WhyNotHugo
added a commit
to WhyNotHugo/domain
that referenced
this issue
Sep 16, 2024
This somewhat simplifies usage for call sites. They no longer need to use `&&StubResolver` for some APIs, and a future can be handed off without being tied to the lifetime of the resolver. The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data. This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release. Fixes: NLnetLabs#175
WhyNotHugo
added a commit
to WhyNotHugo/domain
that referenced
this issue
Nov 11, 2024
This somewhat simplifies usage for call sites. They no longer need to use `&&StubResolver` for some APIs, and a future can be handed off without being tied to the lifetime of the resolver. The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data. This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release. Fixes: NLnetLabs#175
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the
Resolvertrait is only implemented on&StubResolverto bind the future to the information in the resolver. This should be changed and this information be stored behind an arc so you can share the stub resolver for multiple calls. Maybe this should be made explicit byimpl Resolver for Arc<StubResolver>.The text was updated successfully, but these errors were encountered: