OS specific File APIs

[nomad010]

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.

[Darksonn]

I am fine with adding this. Consider taking a look at #2524 and #2515 for inspiration.

[Yoric]

So, porting FileExt? If it's low-priority, I could take a look.

[Darksonn]

Our priority is currently things on the v0.3 and v1.0 milestones, but feel free to take a look.

[Yoric]

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!

[Yoric]

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)

[Darksonn]

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.