WebAssembly
[0.3.0-draft] Can calls to `set-stdout`/`set-stderr` overwrite each other?
In the 0.3.0-draft stdio.wit, the (currently undocumented) set-stdout and set-stderr functions raise the question of what happens when they are called more than once (either by the same component or by multiple subcomponents of a composed component). Will the last call overwrite any previous calls? If not, perhaps we should rename the functions to e.g. add-stdout/add-stderr and document that the stream parameter will be added to the set of streams sent to stdout/stderr rather than replacing the previous stream.
if they behave like unix where you can dup2 to replace stdout/stderr's file descriptors (which is what i'd expect), they discard any previous values.
Replacing a global singleton could result in unexpected runtime behavior. Suppose two independent libraries (e.g. wasi-libc and some hypothetical tokio-wasip3) are both compiled into a single component and both want to write to stdout and call set-stdout; the output of one of them would silently vanish.
IMO, either set-* should fail/trap if it is already configured, or we should change the name & semantics to add-* as you suggested 👍 .
The get-stdout/err pattern was designed to be called multiple times because, as @badeend says, multiple independent libraries are compiled into the same component and all need their writes to make it to stdout/stderr. A big motivator here is that stdout/stderr are very often used for debugging, and swallowing the user's debugging prints because they linked with some other code could be extremely frustrating. The p3 rendering of stdout/err will have to accommodate that same need. The suggestion to change the name to add-stdout/err is fine with me, but I also think its fine to call it set-stdout/err and document this behavior.
I agree that clear documentation is the main thing here. While we're bikeshedding the names, though: perhaps write-to-stdout/write-to-stderr?
I think this conversation has been superseded by https://github.com/WebAssembly/wasi-cli/issues/65 and https://github.com/WebAssembly/wasi-cli/pull/82.
