-
Notifications
You must be signed in to change notification settings - Fork 26
Open
Description
This is a enhancement request to support an async interface to FATX functions, for use in environments that require an asynchronous interface like wasm. This requires replacing std::fs::File as the underlying block device, and any std::io::Read, std::io::Seek or std::io::Write interfaces with traits that support asynchronous operations.
To my knowledge there are three options for supporting this functionality (with varying maintenance burden) as a result of function coloring:
- Duplicate any function that requires reading/writing to the underlying block devices, with a sync and async version. This has the highest maintenance burden, and is likely untenable (but included for completeness).
- Use https://crates.io/crates/maybe-async to toggle the async-ness of functions at compile time using a feature. This is the approach done by xdvdfs, and it is effective except when calling functions from an external library that are not asynchronous, or when behavior needs to deviate based on async/sync (e.g. locking a Mutex, where the async path requires an async-aware Mutex type). The benefit is that there is no impact to runtime/code size when compiling for the synchronous path.
- Implement all functionality in async functions, and add sync wrappers that use a single-threaded executor to call the asynchronous implementation. This is the approach done by https://gitlab.com/hreitz/imago (see https://gitlab.com/hreitz/imago/-/blob/main/src/qcow2/sync_wrappers.rs?ref_type=heads), but has some (potentially minimal) overhead due to the executor. Placing the sync wrappers behind a feature allow for the executor dependencies to be excluded if not needed (which is a benefit on the web, where executors are not useful).
Metadata
Metadata
Assignees
Labels
No labels