Struct FuturesIo 

pub struct FuturesIo<S> { /* private fields */ }

Bridges futures_io::{AsyncRead, AsyncWrite} → hyper::rt::{Read, Write}.

hyper-util only ships TokioIo; smol-hyper 0.1.1 has been dead since 2023-12-29 and bridges in the opposite direction. Without this bridge, the smol backend doesn’t exist.

The implementation is unsafe-free: it reads into a scratch buffer and copies out through the safe ReadBufCursor::put_slice — exactly the technique hyper::rt::Read’s documentation recommends. The cost is one copy per read; zero-copy would require unsafe (ReadBufCursor::as_mut/advance), and the crate declares #![forbid(unsafe_code)] — deliberately deferred.

Implementations

impl<S> FuturesIo<S>

pub fn new(inner: S) -> Self

pub fn into_inner(self) -> S

pub fn get_ref(&self) -> &S

Trait Implementations

impl<S: Debug> Debug for FuturesIo<S>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<S: AsyncRead + Unpin> Read for FuturesIo<S>

fn poll_read( self: Pin<&mut Self>, cx: &mut Context<'_>, buf: ReadBufCursor<'_>, ) -> Poll<Result<()>>

Attempts to read bytes into the buf.

impl<S: AsyncWrite + Unpin> Write for FuturesIo<S>

fn is_write_vectored(&self) -> bool

futures_io::AsyncWrite gives no way to ask S whether its vectored write is efficient: the trait has no is_write_vectored method at all — only poll_write, poll_write_vectored, poll_flush, poll_close. The default poll_write_vectored implementation in futures-io 0.3.33 writes only the first non-empty buffer (futures_io::AsyncWrite::poll_write_vectored, checked against the dependency’s source); for any S that hasn’t overridden it, a vectored write silently degrades into one ordinary write — more syscalls, not fewer.

hyper documents this method as a promise of an “efficient” poll_write_vectored implementation and branches on it to decide whether to coalesce buffers before writing. Returning true here would assert something we have no way to back up — and a capability that lies is worse than one that’s absent, because the calling code (here, hyper itself) branches on it. The honest, conservative answer is false.

If a concrete S shows up for which vectored writes are provably efficient, the right path is a separate constructor with an explicit opt-in, not an optimistic default here. There is no such consumer today, so adding one would be speculative API with no caller.

fn poll_write( self: Pin<&mut Self>, cx: &mut Context<'_>, buf: &[u8], ) -> Poll<Result<usize>>

Attempt to write bytes from buf into the destination.

fn poll_flush(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<()>>

Attempts to flush the object.

fn poll_shutdown(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<()>>

Attempts to shut down this writer.

fn poll_write_vectored( self: Pin<&mut Self>, cx: &mut Context<'_>, bufs: &[IoSlice<'_>], ) -> Poll<Result<usize>>

Like poll_write, except that it writes from a slice of buffers.