c-api: add wasi_config_set_stdout_pipe
As discussed in issue #4372 and respective issues about python and go bindings.
Can replace wasi_config_inherit_stdout in examples/wasi/main.c:79
wasi_config_t *wasi_config = wasi_config_new();
assert(wasi_config);
wasi_read_pipe_t *wasi_stdout_reader = NULL;
wasi_write_pipe_t *wasi_stdout_writer = NULL;
wasi_pipe_new(32, &wasi_stdout_reader, &wasi_stdout_writer);
assert(wasi_stdout_reader && wasi_stdout_writer);
wasi_config_set_stdout_pipe(wasi_config, wasi_stdout_writer);
error = wasmtime_context_set_wasi(context, wasi_config);
// run...
size_t expected = wasi_read_pipe_len(wasi_stdout_reader);
byte_t *buf = malloc(expected);
size_t filled = wasi_read_pipe_read(wasi_stdout_reader, buf, expected);
fprintf(stderr, "Pipe:\n%.*s\n", (int)filled, buf);
wasi_read_pipe_delete(wasi_stdout_reader);
See https://github.com/ShuP1/wasmtime/commit/d818f6b8153c71f94283aa0e9c258e57e795e019
This PR replaces #5189 (cc @alexcrichton)
Are the pipes safe to span threads? Safe to move to another thread but may lock.
Or even maybe dead lock during concurrent use ? This reaches the limit of my understand of rust async...
https://docs.rs/wasi-common/latest/src/wasi_common/pipe.rs.html#112
RwLock is locked in an async function who does not use await.
So no "context switch" ? and no risk for another thread to hung on this lock ?
I'd avoid wasm_byte_vec_t as it's cumbersome to work with and instead use read/write-style buffer passing
Does this point also includes changing that ?
void wasi_config_set_stdin_bytes(wasi_config_t* config, wasm_byte_vec_t* binary);
// to
void wasi_config_set_stdin_bytes(wasi_config_t* config, const byte_t*, size_t);
Subscribe to Label Action
cc @peterhuene
Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:c-api
To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.