-
-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
Resolver
trait is only implemented on&StubResolver
to 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: