-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Allow different Handles to act as stdio #1600
Conversation
Subscribe to Label Actioncc @kubkon
This issue or pull request has been labeled: "wasi"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:c-api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
f62a3f6
to
05c278d
Compare
This looks great! FWIW, I was about to open an issue asking for exactly this, for wasmtime-async, so that it'd be possible to create a WASI context that uses async functions (potentially with blocking tasks, especially for file IO). However, it looks like |
@sunfishcode @pchickey Could you guys take a look and let me know if we're up for merging this change in, or would we rather wait for virtual dispatcher? Given that there a few reports from the users that this is a useful change, I'd vote for merging it in, and then redoing it when virtual dispatcher lands, but if you feel otherwise, I'm OK with it as well. |
Bump ping @kubkon @sunfishcode @pchickey. This blocks the |
There have been requests to allow more than just raw OS handles to act as stdio in `wasi-common`. This commit makes this possible by loosening the requirement of the `WasiCtxBuilder` to accept any type `T: Handle + 'static` to act as any of the stdio handles. A couple words about correctness of this approach. Currently, since we only have a single `Handle` super-trait to represent all possible WASI handle types (files, dirs, stdio, pipes, virtual, etc.), it is possible to pass in any type to act as stdio which can be wrong. However, I envision this being a problem only in the near(est) future until we work out how to split `Handle` into several traits, each representing a different type of WASI resource. In this particular case, this would be a resource which would implement the interface required for a handle to act as a stdio (with appropriate rights, etc.).
@peterhuene this should be it. If you could double check that this indeed fixes #1735 in dotnet side that’d be great. When you confirm everything is green, I reckon we can go ahead and merge this in. |
I'll write some docs for the newly exported types so that we can get this merged today. |
Oh nice one, thanks @pchickey, and apologies I’ve not done this earlier myself! |
I'll test this shortly with the .NET API and get back to you. |
I can confirm this fixes #1735. |
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.
Just that one (nit) comment and the missing docs and this LGTM! Thanks!
crates/c-api/src/wasi.rs
Outdated
))) | ||
} | ||
|
||
fn wasi_preview_builder(config: wasi_config_t) -> Result<WasiPreview1CtxBuilder> { |
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.
Should this function be merged with create_preview1_instance
like create_snapshot0_instance
is implemented?
@kubkon It looks like for |
The output of Apologies for posting a patch for some docs I added, I don't have any way to push to your branch since its in a different repo. (Do you not have write privs on this one? If not we should fix that)
|
Oh right, no, this was intentional. For the time being, the only way to create either of those is using Here's an example usage I've had in mind: let some_file = OpenOptions::new().open("some_file")?;
let os_file = OsFile::try_from(some_file)?; Having said all that, I'm happy to add an explicit constructor for this to make it more readable and usable, something like |
Hmm, I thought you should be able to push directly to my branch in my fork. And yes, I do have write permissions, however, I always prefer to work out of my fork so as to shield myself from stupid mistakes such as force-pushing into |
Signed-off-by: Jakub Konka <kubkon@jakubkonka.com>
@pchickey I've applied your patch (thanks!), and extended the docs with some constructing examples. Have a look and lemme know what you reckon! |
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.
Thanks for the explanation, I had missed that try_from File was the way to construct these, the updates to the docs are very welcome there. As soon as CI finishes this looks ready to merge
There have been requests to allow more than just raw OS handles to act as stdio in
wasi-common
(see #939). This PR makes this possible by loosening the requirement of theWasiCtxBuilder
to accept any typeT: Handle + 'static
to act as any of the stdio handles.A couple words about correctness of this approach. Currently, since we only have a single
Handle
super-trait to represent all possible WASI handle types (files, dirs, stdio, pipes, virtual, etc.), it is possible to pass in any type to act as stdio which can be wrong. However, I envision this being a problem only in the near(est) future until we work out how to splitHandle
into several traits (FYI @sunfishcode and I have already started figuring this out), each representing a different type of WASI resource. In this particular case, this would be a resource which would implement the interface required for a handle to act as a stdio (with appropriate rights, etc.).@jeffcharles @pchickey The minimum this PR still needs is an audit of this approach for the time being (whether it's OK to go with it given the potential correctness problems I've outlined above). Docs around different now-public types are also a must if we decide to go with it. Oh, and I haven't really got to testing this approach, i.e., whether this is actually sufficient of a change to facilitate the requirements of #939. Any comments and feedback is thus most welcome!
Closes #939, #1636, #1735