Make serve generic over the listener and IO types
#2479
Conversation
axum/src/serve.rs
Outdated
| /// TODO | ||
| pub trait Listener: Send + 'static { | ||
| /// The listener's IO type. | ||
| type Io: AsyncRead + AsyncWrite + Unpin + Send + 'static; | ||
|
|
||
| /// The listener's address type. | ||
| type Addr: Send; | ||
|
|
||
| /// Accept a new incoming connection to this listener | ||
| fn accept(&mut self) -> impl Future<Output = io::Result<(Self::Io, Self::Addr)>> + Send; | ||
|
|
||
| /// Returns the local address that this listener is bound to. | ||
| fn local_addr(&self) -> io::Result<Self::Addr>; | ||
| } |
There was a problem hiding this comment.
We could also use tokio-util's Listener trait however I don't think tokio-util should be in our public API. By writing our own we can also use async fn accept rather than fn poll_accept.
|
Just wanted to add a friendly +1 to these changes — this is precisely a fit for something I'm working on right now, and would make life dramatically easier as compared with the boilerplate currently necessary to do this manually. |
|
Is any help needed to bring this change over the finish line? |
Nope. Its a breaking change and don't wanna start merging breaking PRs just yet. It is done otherwise. |
I'm not involved with the project, but seeing as this is a breaking change, it's slotted for 0.8 as far as I can tell, so not sure how soon it will be until this is merged. As a workaround for myself, I cloned the project and merged this PR specifically into the latest version. If it's viable to use for your situation, you can patch it in via the below snippet. I'm using this in prod with no issues, but YMMV obviously. # in your Cargo.toml
[patch.crates-io]
axum = { git = "https://github.com/lojewalo/axum.git", branch = "uds-v0.7.3" } |
|
Thanks for doing that @lojewalo, I'll do that, and I'll report if I run into any sharp edges. Thanks for everyone's work on such an awesome library! 😎 |
|
I came here via the issue #2494. If this makes it easier to accept tls connections, could you also provide an example how to do it without the I am at the moment a bit frustrated about the slow maintenance of the |
|
Any updates on where this stands with the maintainers? do you want to experiment with different designs or can this be merged as-is? |
|
This is a PR by the primary maintainer, approved by the co-maintainer. It's going to land, the question is just when. Which I unfortunately can't give you any details about, you're just going to have to be patient (or use this branch via |
|
This PR is added to 0.8 milestone. Will it land when 0.8 publishes? |
|
Yes. It will be merged some time before we publish v0.8.0. |
It's too complex to bother with for the current `axum` API. Let's wait for axum 0.8 release. Ref: tokio-rs/axum#2479
|
Closing in favor of #2941. |
Based on #2478
Fixes #2474
It's actually not as bad as I had feared so I think we can do this for 0.8.