starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #310] Making the ServerFuture an actual future #437

New issue

Closed

opened 2026-03-15 22:29:06 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 22:29:06 +03:00

Owner

Originally created by @vorner on GitHub (Dec 2, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/310

Currently, the ServerFuture creates its own Core. This is a common anti-pattern in many crates that they insist on creating their own core, which means if I want to have multiple ServerFuture's, or a ServerFuture and hypers HTTP server in one process, each needs to have its own thread.

The better way would be for the ServerFuture to actually be a future (maybe something like Future<Item = (), Error = io::Error>. That way I could create the server, compose it within some larger future (shutdown & error handling, for example) and spawn it onto my own core.

Originally created by @vorner on GitHub (Dec 2, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/310 Currently, the ServerFuture creates its own `Core`. This is a common anti-pattern in many crates that they insist on creating their own core, which means if I want to have multiple ServerFuture's, or a ServerFuture and hypers HTTP server in one process, each needs to have its own thread. The better way would be for the ServerFuture to actually *be* a future (maybe something like `Future<Item = (), Error = io::Error>`. That way I could create the server, compose it within some larger future (shutdown & error handling, for example) and spawn it onto my own core.

kerem

2026-03-15 22:29:06 +03:00

closed this issue
added the
enhance

crate:server

cleanup
labels

kerem commented

2026-03-15 22:29:22 +03:00

Author

Owner

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

As an aside, the reason for this is baked into the history of the project. It was never clear to me that people might want to have the DNS Server be a library, but of course that was short sighted... It should be fairly easy to refactor the ServerFuture to move the Core out and possibly the core.run into the named binary itself to drive it.

@bluejekyll commented on GitHub (Dec 4, 2017): As an aside, the reason for this is baked into the history of the project. It was never clear to me that people might want to have the DNS Server be a library, but of course that was short sighted... It should be fairly easy to refactor the ServerFuture to move the `Core` out and possibly the `core.run` into the named binary itself to drive it.

kerem commented

2026-03-15 22:29:27 +03:00

Author

Owner

@DemiMarie commented on GitHub (Mar 19, 2018):

@bluejekyll I can think of several reasons; for instance, one might want to have a single process containing a DNS server, an SMB server, an LDAP server, and a Kerberos KDC, so that a single process can act as a complete Windows domain controller.

@DemiMarie commented on GitHub (Mar 19, 2018): @bluejekyll I can think of several reasons; for instance, one might want to have a single process containing a DNS server, an SMB server, an LDAP server, and a Kerberos KDC, so that a single process can act as a complete Windows domain controller.

kerem commented

2026-03-15 22:29:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 19, 2018):

I can definitely see the value in doing this. I’ve planned on doing this work, but just haven’t gotten the time. I agree that it should be done.

@bluejekyll commented on GitHub (Mar 19, 2018): I can definitely see the value in doing this. I’ve planned on doing this work, but just haven’t gotten the time. I agree that it should be done.

kerem commented

2026-03-15 22:29:37 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 19, 2018):

And that’s a really neat idea.

@bluejekyll commented on GitHub (Mar 19, 2018): And that’s a really neat idea.

kerem commented

2026-03-15 22:29:42 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 9, 2019):

I'm going to close this, as I think the ServerFuture and other supporting types like Catalog and Authority are in good shape for any Async work needed. We can reopen, or open another issue if changes are desired.

@bluejekyll commented on GitHub (Apr 9, 2019): I'm going to close this, as I think the ServerFuture and other supporting types like Catalog and Authority are in good shape for any Async work needed. We can reopen, or open another issue if changes are desired.

kerem referenced this issue

2026-03-16 02:06:29 +03:00

[PR #438] [MERGED] Switch to tokio-executor, drop use of tokio_core::reactor::Handle #1436

kerem referenced this issue

2026-03-16 02:06:29 +03:00

[PR #437] [CLOSED] Switch to tokio-executor, drop use of tokio_core::reactor::Handle #1439