You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
use bytes::BytesMut;use monoio::net::TcpStream;pubstructOneStream{inner:TcpStream,meta:Meta,}implOneStream{asyncfnfrom_tcp(raw:TcpStream) -> Result<Self,crate::Error>{let len = raw.read_u8().await?;letmut buf = BytesMut::with_capacity(len asusize);let a = raw.read_exact(buf).await;todo!("a lot work needed to parse a")}
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.
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.
The text was updated successfully, but these errors were encountered: