This was actually brought up as an unresolved question in the ROADMAP. I think I mentally dismissed it at some point as just being annoying, but in the past week as I've thought about how we could make use of io-uring in hyper, I've been thinking about this again. If nothing else, this should be a public record of the decision, whether for or against. This will help others, including Future Us.
All other integration with a runtime (Tokio) has been removed, and helpers exist in hyper-util
. hyper 1.0 (as of of rc.2) still depends on tokio
with all features turned off, to ask that IO transports implement tokio::io::{AsyncRead, AsyncWrite}
. By doing so, it makes it easier for users to simply supply a tokio::net::TcpStream
. But, let me at least bring up some downsides.
Reasons for hyper::io::{AsyncRead, AsyncWrite}
- For people integrating with other runtimes (curl, fuchsia, etc), it can feel odd to need to pull in
tokio
just to implement the IO traits hyper wants. People have expressed concern that they don't want to compile multiple runtimes. While we can explain it's just the traits (when the features are turned off), owning the traits could make people less confused.
- If we own the traits, we can decide to try different things that perhaps Tokio itself wouldn't want to do. This includes differences in opinion of how vectored reads and writes should be supported, but also means we could try to provide specialization paths for completion-based IO (such as io-uring).
We can provide hyper_util::io::Tokio(T)
that implements the traits for Tokio types, to reduce friction.
B-rfc B-breaking-change A-dependencies