[GH-ISSUE #308] Is trust_dns_server sync or async? #140

New issue

Closed

opened 2026-03-07 22:25:55 +03:00 by kerem · 4 comments

kerem commented

2026-03-07 22:25:55 +03:00

Owner

Originally created by @vi on GitHub (Dec 1, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/308

One one hand I see refences to Tokio and things.

On the other, trust_dns_server::server::RequestHandler's fn handle_request(&self, request: &Request) -> Message returns plain Message instead of Future<Message>, so expected to be instantaneous. How then should one implement proxies or replicated servers or something like that? Or does it happen in some thread pool?

In any case the documentation should be extended.

Originally created by @vi on GitHub (Dec 1, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/308 One one hand I see refences to Tokio and things. On the other, `trust_dns_server::server::RequestHandler`'s `fn handle_request(&self, request: &Request) -> Message` returns plain `Message` instead of `Future<Message>`, so expected to be instantaneous. How then should one implement proxies or replicated servers or something like that? Or does it happen in some thread pool? In any case the documentation should be extended.

kerem

2026-03-07 22:25:55 +03:00

closed this issue
added the
duplicate
label

kerem commented

2026-03-07 22:26:26 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 1, 2017):

The server hasn't gotten a lot of treatment to be used internally, or be exposed to be used inside other software at the moment. I do see the value in this, but it's not be high priority at the moment. You're correct that a lot of the library keeps internal references to the reactor::Core and and other async components.

I'd be happy to start making the server easier to use inside other libraries, so if you have changes you'd like to see to make that easier, let's definitely file issues for that use case.

btw, to answer the question directly, the Server is async, it's just not easily embeddable in other software at the moment.

@bluejekyll commented on GitHub (Dec 1, 2017): The server hasn't gotten a lot of treatment to be used internally, or be exposed to be used inside other software at the moment. I do see the value in this, but it's not be high priority at the moment. You're correct that a lot of the library keeps internal references to the reactor::Core and and other async components. I'd be happy to start making the server easier to use inside other libraries, so if you have changes you'd like to see to make that easier, let's definitely file issues for that use case. ---- btw, to answer the question directly, the Server is async, it's just not easily embeddable in other software at the moment.

kerem commented

2026-03-07 22:26:31 +03:00

Author

Owner

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

This is a duplicate of #309

@bluejekyll commented on GitHub (Dec 15, 2017): This is a duplicate of #309

kerem commented

2026-03-07 22:26:36 +03:00

Author

Owner

@vi commented on GitHub (Dec 16, 2017):

So the answer is "it is async, but need to fix some issues".

@vi commented on GitHub (Dec 16, 2017): So the answer is "it is async, but need to fix some issues".

kerem commented

2026-03-07 22:26:41 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 16, 2017):

To be accurately, internally it is async, but I never really exposed a library interface to use it inside something other than the named binary.

So yes, there is some minor cleanup needed to expose the futures based interfaces properly.

@bluejekyll commented on GitHub (Dec 16, 2017): To be accurately, internally it is async, but I never really exposed a library interface to use it inside something other than the named binary. So yes, there is some minor cleanup needed to expose the futures based interfaces properly.

kerem referenced this issue

2026-03-16 01:56:59 +03:00

[PR #140] [MERGED] fix the timeout clone in ClientError #1261