Open FrankReh opened 2 years ago
@Noah-Kennedy @mzabaluev @ollie-etl thoughts?
It's interesting that all I/O operations take &self
. This is good for File
because there is no internal cursor and operations can be scheduled concurrently. But this constitutes a larger commitment to not have any mutable state in userspace behind the I/O objects. TcpStream
in tokio does the same in the inherent methods, so it's not without precedent.
Tokio needed into_split
so perhaps it's needed here as well.
Since yesterday, I'm running TcpStream and UdpSocket reads and writes from separate tasks by wrapping them in Rc\<RefCell\
Like tokio::io::split, tokio-uring should allow splitting things like TCP and UDP streams and perhaps Files into reader and writer halves so separate tasks could be reading and writing concurrently.
Each task would end up awaiting one of the read or one of the write operations so it is not possible to borrow the stream from an Rc\<RefCell\>-like structure in two tasks concurrently. We don't currently have traits defining the read and write halves, like the AsyncRead and AsyncWrite of tokio so this doesn't seem possible yet.Just looked and all the read and write operations defined on tokio-uring TcpStream take &self so maybe it's possible to just use it twice concurrently, in the meantime.