Status: WIP, not yet ready for merging.
Request: Generally just wanted other eyes on it
Summary of Changes:
Introduction of futures Feature: This new feature introduces support for async-std and any other runtime that relies on futures_io::AsyncRead/Write.
New Traits: rt::Read and rt::Write: These traits serve as thin wrappers around tokio::io::AsyncRead/Write and any type that implements futures_io::AsyncRead/Write. Maintains tokio as a first class citizen + support for other runtimes
Custom ReadBuf Future Implementation for futures_io::AsyncRead: Due to differences in API surface between futures_io::AsyncRead and tokio::io::AsyncRead, I made a custom impl - (Soundness/Safety guarantees are still up for debate)
Async fn: The new traits return an impl std::future::Future<Output = _>. Initial attempts to declare them as async fn were unsuccessful, but this allows them to be used across runtimes.
Testing and Examples: All tests and examples within the tests directory and examples have been successfully executed, both with and without the feature flag via cargo run --feature futures --example <example> or cargo test --feature futures. The only exception were the documentation tests, which I didn't want to change but don't see why they wouldn't work.
Dependency Update: The only new dependency introduced is futures_lite@2.2.0, for [dev-dependencies] we tested with async-std and futures_rustls . async_std needed the unstable feature flag for async-std for task::spawn_local and the atrributes flag for async_std::main.
Also bumped webpki-roots from 0.23.0 -> 0.25.2
Troubles
In src/handshake ran into a problem where I couldn't change the trait bounds to rt::Read/Write - believe the full solution there would be to implement in full a AsyncRead/Write interface - similar to what hyper did with their traits here, but I just wanted to get something up and running. Something like hyper's is probably more ideal, and should be the target. ATM I'm implicitly targeting Glommio as io_uring library of choice here since it impls future_io, so easier to work with + they've shown that they're capable of working with hyper here - but if this PR ends up with something similar to Hyper's traits then it'll probably end up with the main library changing to runtime agnostic interfaces and then writing runtime specific compat layers gated by feature flags so extensions would be possible.
Want to test with Glommio' since their IO impl futures_io::AsyncRead/Write since async-std works okay so far
Status: WIP, not yet ready for merging. Request: Generally just wanted other eyes on it Summary of Changes:
async-stdand any other runtime that relies onfutures_io::AsyncRead/Write.rt::Readandrt::Write: These traits serve as thin wrappers aroundtokio::io::AsyncRead/Writeand any type that implementsfutures_io::AsyncRead/Write. Maintainstokioas a first class citizen + support for other runtimesReadBufFuture Implementation forfutures_io::AsyncRead: Due to differences in API surface betweenfutures_io::AsyncReadandtokio::io::AsyncRead, I made a custom impl - (Soundness/Safety guarantees are still up for debate)impl std::future::Future<Output = _>. Initial attempts to declare them as async fn were unsuccessful, but this allows them to be used across runtimes.cargo run --feature futures --example <example>orcargo test --feature futures. The only exception were the documentation tests, which I didn't want to change but don't see why they wouldn't work.futures_lite@2.2.0, for[dev-dependencies]we tested withasync-stdandfutures_rustls.async_stdneeded the unstable feature flag forasync-stdfortask::spawn_localand the atrributes flag forasync_std::main.webpki-rootsfrom 0.23.0 -> 0.25.2Troubles
In src/handshake ran into a problem where I couldn't change the trait bounds to
rt::Read/Write- believe the full solution there would be to implement in full aAsyncRead/Writeinterface - similar to what hyper did with their traits here, but I just wanted to get something up and running. Something like hyper's is probably more ideal, and should be the target. ATM I'm implicitly targeting Glommio as io_uring library of choice here since it implsfuture_io, so easier to work with + they've shown that they're capable of working with hyper here - but if this PR ends up with something similar to Hyper's traits then it'll probably end up with the main library changing to runtime agnostic interfaces and then writing runtime specific compat layers gated by feature flags so extensions would be possible.Want to test with Glommio' since their IO impl
futures_io::AsyncRead/Writesince async-std works okay so far