Roadmap for File I/O

[stsydow]

I'm have ported my code from v0.1 to v0.3 it feels not good
as there are API changes and performance regressions,
I don't understand. (#2994 is a result)

• Why is having a API with &File instead of &mut File worth the Mutex in File which is very slow now?
• Is tokio mostly about task execution (in practice web requests) and networking?

My expectation was that tokio is the "batteries included solution" for async processing.
But lately Sinks, Streams and Codecs where dropped or moved to tokio_util and
now File I/O is not a priority. That is quite a surprise.

I just discovered the AsyncFD issue #2903 and mio::unix, which is at least a good base for Unix File I/O.
And there is also async_fs (using an extra I/O thread) - which is better at least than the current approach.

I'm willing to contribute, but the code is so complex already that I would appreciate some hints how to approach it and what to expect.

[Darksonn]

I just discovered the AsyncFD issue #2903 and mio::unix, which is at least a good base for Unix File I/O.

No, it cannot be used with file IO. It might seem like it would work, but the underlying OS primitives don't work with files.

And there is also async_fs (using an extra I/O thread) - which is better at least than the current approach.

This is the current approach. In fact, having another look at your code, it seems like you only use read and write (and wrappers of those two) which in fact bypass the mutex entirely using Mutex::get_mut, so it's surprising that you see the increased usage of mutex. I guess that the issue deserves another look, because the mutex that was introduced in #2930 shouldn't be the cause.