Open nomad010 opened 4 years ago
I am fine with adding this. Consider taking a look at #2524 and #2515 for inspiration.
So, porting FileExt
? If it's low-priority, I could take a look.
Our priority is currently things on the v0.3 and v1.0 milestones, but feel free to take a look.
Our priority is currently things on the v0.3 and v1.0 milestones, but feel free to take a look.
Is there some issue where I would be more useful? I'm fairly new at tokio, but happy to learn!
Ok, I've toyed with it a little and I have an early prototype of poll_read_at
and a few difficulties deciding where it should go.
Should I introduce
/// Implemented by `std::fs::File` under Unix.
pub trait ReadAt {
fn read_at(&self, buf: &mut [u8], offset: u64) -> std::io::Result<usize>;
}
pub trait AsyncReadAt {
fn poll_read_at(
self: Pin<&mut Self>,
cx: &mut Context<'_>,
buf: &mut ReadBuf<'_>,
offset: u64
) -> Poll<io::Result<()>>;
}
and
pub trait AsyncReadAtExt {
fn read_exact<'a>(&'a mut self, buf: &'a mut [u8]) -> ReadExact<'a, Self>;
}
?
(and later the same with poll_seek_read
under Windows)
Having a poll version of it raises a bunch of questions regarding how to design it correctly. I think it is best to wait with this particular feature for now. See the "Pause on adding new APIs" section in #2718, where it is outlined that we currently only accept obviously correct API additions.
I will be happy to provide guidance regarding other places to contribute now on our discord server.
It would be nice to have the OS specific implementations of File Read/Write methods in tokio as a nice to have. I noticed that there was a closed PR on the topic here #488 and the commits have become stale in the meantime.
Is there any resistance to this feature? Would this be doable as a first issue? If so, I'd like to try my hand at implementing it.