-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable cfg_fs for wasi #6822
Enable cfg_fs for wasi #6822
Conversation
Is there a maintainer who can review this PR? Our team primarily uses WASI, but this issue is a major obstacle in using Tokio with WASI. We would greatly appreciate any help. |
I believe that this was added because |
Yes, this works well. I have already forked Tokio and am using Tokio FS in a web browser with the fixes from this PR. However, I decided to create this PR because using the fork continuously could cause compatibility issues with other crates. Not all WASM, or more specifically, WASI, is single-threaded. Among Rust targets, there are WASI support in Tokio is already experimental. Also, since WASI itself is quite experimental, I believe most WASI users would typically check whether the WASI runtime they are using supports threads or not. Therefore, I don't think there would be a significant issue in opening up the configuration to allow using Tokio FS in WASI environments that do support threads. |
Ok, I don't mind adding this. There's a compilation failure, though. tokio/tokio/src/fs/open_options.rs Lines 396 to 399 in 9116999
We can fix it like this: /// Returns a mutable reference to the underlying `std::fs::OpenOptions`
#[cfg(any(windows, unix))]
pub(super) fn as_inner_mut(&mut self) -> &mut StdOpenOptions {
&mut self.0
} |
If the compile error is due to the function not being used in WASI, would it be okay to include a fix for that in this PR as well? It might be a good idea for me to modify the PR to ensure there are no compile errors overall and then request a review from you. |
Go ahead. |
I thought I would need more changes, but it's not. There's nothing more except for the modifications you mentioned. Please check. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
Github Action Canceled https://github.com/tokio-rs/tokio/actions/runs/10803632984/job/29967823508?pr=6822 |
You don't need to do anything. I will rerun. |
@Darksonn If it's not too much trouble, may I ask when this change is expected to be released? |
We don't have very many changes since the last release, so it may be another month. But if you are willing to do the work of preparing the release, we can make one now. |
After reviewing this document (https://github.com/tokio-rs/tokio/blob/master/CONTRIBUTING.md#releasing), I believe I can handle it. I have some other tasks to finish first, but once I'm done, I'll create a PR for the release. |
The part about path dependencies isn't needed anymore, so you can skip that step. |
Motivation
We are currently using
wasip1-threads
and have implemented our ownwasi fs
. However, there is a restriction that prevents using the file system feature whencfg_fs
is set towasi
. I believe this restriction should be lifted, as it contradicts the intention stated in the Tokio code, where enabling thetokio_unstable
flag allows the use of the file system feature (relevant code link).Solution
I have removed the
wasi
condition fromcfg_fs
to enable the file system feature. After forking Tokio and applying this change, I tested it and found that it works perfectly. This change will allow support for the file system feature in thewasip1-threads
environment.