rust-fatfs icon indicating copy to clipboard operation
rust-fatfs copied to clipboard

Async support?

Open MabezDev opened this issue 3 years ago • 1 comments

We could use the embedded async read/write/seek traits from https://github.com/embassy-rs/embedded-io/blob/master/src/asynch.rs. Note that until GATs are stable, this requires some nightly features. The hard part is how the blocking and async versions should coexist with minimal duplication.

Perhaps everything should be async by default, and users can use futures::block_on or cassette to turn async functions into blocking ones?. This does create awkwardness for use with the standard library as there are no async read/write/seek traits available.

At this point, I'm just throwing some ideas out there, haven't thought too hard about this just yet. This is the most developed and well-tested Rust fatfs implementation (in fact, I've been using it for years at this point!) and it would be great to see some async support.

Edit another, kinda hacky solution: https://github.com/fMeow/maybe-async-rs

MabezDev avatar Jun 21 '22 22:06 MabezDev

There's a newer crate that helps with async/sync: https://docs.rs/maybe-async-cfg/latest/maybe_async_cfg/

I've already had a fair amount of success adapting several other embedded libraries to use it.

quentinmit avatar Aug 14 '22 21:08 quentinmit

Now that GATs are stable we can avoid using unstable features to implement this, do you have any thoughts/opinions on adding async support @rafalh?

MabezDev avatar Dec 21 '22 14:12 MabezDev

After playing around with this crate trying to serve files in a FAT32 image using axum, I have to say that it is not really useful in an async context, since almost everything is !Send and !Sync, and that does not play nicely with Tokio.

kmod-midori avatar Jun 11 '23 07:06 kmod-midori

After playing around with this crate trying to serve files in a FAT32 image using axum, I have to say that it is not really useful in an async context, since almost everything is !Send and !Sync, and that does not play nicely with Tokio.

Whilst use in tokio may be limited, many other executors do not require futures to be Send, in particular, no_std executors don't tend to enforce this. My application of using this crate is in a no_std context where async would make single-thread concurrent operations a breeze.

MabezDev avatar Jun 11 '23 12:06 MabezDev

I have hard-forked this crate to provide async support, and to use the embedded-io traits: https://github.com/MabezDev/embedded-fatfs, feedback and PRs welcome.

MabezDev avatar Sep 04 '23 10:09 MabezDev