Skip to content
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

Better integration of Wasm stderr into Apache's trace #5

Open
gzurl opened this issue Oct 18, 2022 · 0 comments
Open

Better integration of Wasm stderr into Apache's trace #5

gzurl opened this issue Oct 18, 2022 · 0 comments
Labels
🚀 enhancement New feature or request 💡looking for ideas Issue under discussion and looking for new ideas

Comments

@gzurl
Copy link
Contributor

gzurl commented Oct 18, 2022

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.

@gzurl gzurl added 🚀 enhancement New feature or request question Further information is requested 💡looking for ideas Issue under discussion and looking for new ideas and removed question Further information is requested labels Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 enhancement New feature or request 💡looking for ideas Issue under discussion and looking for new ideas
Projects
None yet
Development

No branches or pull requests

1 participant