The signature of monoio::io::AsyncReadRentExt::read_exact is weird.

[RuofengX]

I am using monoio as an alternative to tokio, and I found that it's weird using read_exact method.

In tokio (or std), the function with same name act like this: take the given mutable borrowed buffer, then read bytes into in, until error or the buffer exhausted, at the end, return the count number of bytes that readed, wrapped in a result.

In monoio, this function takes the ownership of the buffer, then write bytes into it, thern return the BufResult (which is alias to a tuple). It is HARD/COMPLEX to parse the result-tuple, also, if the buffer is sent everywhere, I think it cannot be called buffer any more.

I think this behavior is quite weird. I am not sure it is because the inner implement use some non-send magic. Someone please tell me it is necessary. Or it is better to change the api behavior.

[RuofengX]

我贴一个用例

use bytes::BytesMut;
use monoio::net::TcpStream;

pub struct OneStream {
    inner: TcpStream,
    meta: Meta,
}
impl OneStream {
    async fn from_tcp(raw: TcpStream) -> Result<Self, crate::Error> {
        let len = raw.read_u8().await?;
        let mut buf = BytesMut::with_capacity(len as usize);
        let a = raw.read_exact(buf).await;
        todo!("a lot work needed to parse a")
    }

这个用例就是读取流，然后将头部信息解析+保存为meta字段

这里read_exact返回的是一个(Result<usize, io::Error>, BytesMut)，
我理想的情况是传入&mut buf，然后返回Result<usize, io::Error>，这样一次赋值+?语法糖就可以完成解析，也是tokio和标准库的使用体验。

[Lzzzzzt]

The buffer design we refer to the implement of tokio-uring.

When doing the io-uring operations, the kernel will take over the buffer, so the buffer address and its length should be valid during the operations. Also, this kind of design can reduce the copy of data, which could improve performance.

Additionally, there is a short article explains this.