ShuP1 opened issue #4372:
Feature
Rust library can bind WritePipe to WasiCtx stdout which can be far simpler and effective than OS files went dealing with multiple short-lived instances.
It is not currently possible with C/C++ bindings
Benefit
- Avoid useless error-prone and slow interactions by filesystem
- Allow simpler integration in freestanding targets
Implementation
Leverage existing wasi_common::pipe::WritePipe and ReadPipe on the rust side to implemented a binding in
c-api
crate.Alternatives
Export some basic filesystem operations in c binding
alexcrichton labeled issue #4372:
Feature
Rust library can bind WritePipe to WasiCtx stdout which can be far simpler and effective than OS files went dealing with multiple short-lived instances.
It is not currently possible with C/C++ bindings
Benefit
- Avoid useless error-prone and slow interactions by filesystem
- Allow simpler integration in freestanding targets
Implementation
Leverage existing wasi_common::pipe::WritePipe and ReadPipe on the rust side to implemented a binding in
c-api
crate.Alternatives
Export some basic filesystem operations in c binding
gzurl commented on issue #4372:
+1 for this feature.
When embedding Wasmtime in C (or C++), and enabling WASI extensions for a Wasm module, there is no way to capture stdout into a string. The only alternative seems to use [wasi.h]wasi_config_set_stdout_file(), which brings many other drawbacks (ie: no buffering, slow down, etc.)
guregu commented on issue #4372:
Is this the blocker issue for https://github.com/bytecodealliance/wasmtime-go/issues/34 and https://github.com/bytecodealliance/wasmtime-py/issues/34? (cc @alexcrichton)
I would love to switch to wasmtime for my projects but this is preventing me from doing so.
We also need the ability to set a string for stdin as well. I'm not sure if there is a separate issue for that.
alexcrichton commented on issue #4372:
Yes this is required for those issues.
ShuP1 commented on issue #4372:
The binding for
stdout
/stderr
is a bit more complicatedFirst this api needs to return a new opaque struct for retrieve output after
store
drop.Furthermore there is 2 properties of
WritePipe
than should probably be accessible:
- bounded or not:
- provide a
&mut [u8]
for preallocated bounded size- use an internal
Vec<u8>
for unpredictable unbounded size- shared: (note: internally buffer is always in
Arc<RwLock<T>>
)
- WritePipe::new_in_memory can only be read after
store
drop- WritePipe::from_shared allows to read between function calls
ShuP1 commented on issue #4372:
Side question: is
stdin
streaming a desired feature ?wasi_read_pipe_t in; wasi_config_set_stdin_pipe(wasi_config, &in); ... wasi_read_pipe_write(&in, &binary); wasmtime_func_call(...); // consume stdin wasi_read_pipe_write(&in, &binary); wasmtime_func_call(...); wasi_read_pipe_delete(&in);
Last updated: Nov 22 2024 at 16:03 UTC