bmitc commented on issue #136: URL: https://github.com/apache/avro-rs/issues/136#issuecomment-3085093905
> > > File IO is not async anyway. > > > Computation should be sync too. > > > > > > This is not accurate. Tokio provides asynchronous file utilities via [`tokio::fs`](https://docs.rs/tokio/latest/tokio/fs/index.html). For example, [`tokio::fs::File`](https://docs.rs/tokio/latest/tokio/fs/struct.File.html) is `AsyncRead`. > > It is accurate, under the hood Tokio spawns a "blocking" thread which reads the file using std::io and then pushes it to the async runtime It isn't accurate at a practical level. `tokio::fs` exists because there is a need to make file operations behave asynchronously. Whether or not the file operations are actually ascynrhonous is an implementation detail that doesn't support why there shouldn't be an asynchronous version of this Avro reader. The benefits of having this Avro library support `AsyncWrite` and `AsyncRead` are not tied to file operations but are tied to the reasons why async exists in the first place and allowing this Avro library to be more easily integrated into async and concurrent applications. If one wants to stream a lot of Avro data from many sources at the same time, then Tokio is the way to do that, not having to manually manage threads. `SyncIoBridge` works with this library, but it's awkward. Lastly, things that implement `Read` and `AsyncRead` do not always come from files. As many pointed out here, it's common to have Avro data in S3 or other such cloud-based systems, where the data is streamed over HTTP, which _is_ asynchronous. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@avro.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
