Switch tokio AsyncRead/Write traits to futures AsyncRead/Write tr…

[cmeister2]

…aits.

Provide option to switch between async-std and tokio for with_file_async

[drahnr]

@cmeister2 could you resolve the conflicts with master? Let's merge it right after

[cmeister2]

@cmeister2 could you resolve the conflicts with master? Let's merge it right after

Should be resolved.

[drahnr]

One feature gate is missing, other than that, LGTM!

[cmeister2]

One feature gate is missing, other than that, LGTM!

As per comment, I don't think there's a bug here.

[drahnr]

Mea culpa, good to go

[dralley]

@cmeister2 @drahnr I recently learned that all async file I/O in Rust at the moment is actually synchronous I/O backed by a threatpool inside of the async library (tokio or async-std). And apparently there are some additional problems with the specific implementation that makes it extremely slow and not at all worth using unless you're already inside an async framework. Tokio actually recommends against using it if your workload is primarily filesystem-based.

I'm curious if there is an actual use case in mind for this feature with solid backing? At the very least I'm not sure we should have it enabled by default if it doesn't buy the user much over .spawn_blocking().

[drahnr]

It's mostly convenience, not having to deal with the additional complexity of offloading all IO ops manually.

[cmeister2]

Generally if I'm working in async I want everything to be async, including IO operations (even if actually under the covers it's not implemented in a "pure" AIO way. I also believe Linux is making strides towards actual async IO in the kernel, so at some point in the future I could well believe that the async frameworks will just expose the underlying support, and all consumers get improvements for free.

I'm personally fine with not having async on by default though - I think it's something that we should probably have behind the existing feature flags.

[dralley]

I also believe Linux is making strides towards actual async IO in the kernel, so at some point in the future I could well believe that the async frameworks will just expose the underlying support, and all consumers get improvements for free.

It will happen eventually but the improvements won't be free, the polling-based model used by futures / tokio / async-std is incompatible with the completion-based model of io_uring. A lot of the discussion about how to adopt those system APIs revolves around how to design a new set of traits and rewrite large portions of tokio to take advantage of it. Shims might be possible but it would come at the expense of performance.

I guess my main question is whether a user has ever articulated a compelling need for it yet. Or if we know of any that are actually using it this way.

[drahnr]

It's already there, the user is not forced to use it. I'd prefer to leave a comment on the relevant functions, after all, we will see where things settle down regarding Io in executors. Out of our scope.