Description
Currently, when building the WASI context for the Wasm module, it inherits stderr from the Apache process. So all the output to stderr becomes part of the Apache's error_log file, but it's not really integrated into the Apache trace.
NOW:
[Tue Sep 06 20:09:17.733094 2022] [core:notice] [pid 2074:tid 140335383988096] AH00094: Command line: './httpd'
Hello, Wasm! (@stderr)
DESIRED:
[Tue Sep 06 20:09:17.733094 2022] [core:notice] [pid 2074:tid 140335383988096] AH00094: Command line: './httpd'
[Tue Sep 06 20:09:17.749431 2022] [core:notice] [pid 2074:tid 140335383988096] Hello, Wasm! (@stderr)
To solve this, we can replicate the implementation for stdout, by having a new Vec<u8> buffer and another WritePipe for the WasiCtx.
But the main difference with stdout is when to read it. The stdout is read at the end of the execution (and that seems fine). On the other hand, we might want an error sent to stderr to be printed out to the trace as soon as it happens, so it also gets the right time marks.
So, there is no straightforward solution: either we somehow 'listen' to the pipe for new lines, or we might need to read on a time basis (every second?) and pull for new lines during the Wasm execution.
Also, we need to consider how it is returned from wasm_runtime.so to mod_wasm.so; probably by returning a struct to C, so wasm_runtime_run_module() -> *const c_char would become kind of wasm_runtime_run_module() -> struct stdio { *const c_char, *const c_char }. In this regard, this issue is related to #4 since it requires solving how structs can be returned from Rust to C.