Skip to content
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

Open
partim opened this issue Feb 15, 2023 · 0 comments · May be fixed by #393
Open

Make the stub resolver shareable. #175

partim opened this issue Feb 15, 2023 · 0 comments · May be fixed by #393

Comments

@partim
Copy link
Member

partim commented Feb 15, 2023

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 by impl Resolver for Arc<StubResolver>.

@partim partim added this to the 0.8.0 milestone Feb 15, 2023
@partim partim modified the milestones: 0.8.0, 0.9.0 Apr 20, 2023
@partim partim removed this from the 0.10.0 milestone Mar 21, 2024
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 WhyNotHugo linked a pull request Sep 16, 2024 that will close this issue
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant