Closed lcrilly closed 3 months ago
Update.
This may or may not be related but after configuring a wasm-wasi-component
application and then replacing the configuration with a different (single) application, the original Wasm app processes (prototype and app) persist (when they should not).
Yes, sounds like something funky going on, looking at it...
The processes weren't exit(2)ing..
Try this
diff --git a/src/wasm-wasi-component/src/lib.rs b/src/wasm-wasi-component/src/lib.rs
index 3ee40c4f..47c94bdc 100644
--- a/src/wasm-wasi-component/src/lib.rs
+++ b/src/wasm-wasi-component/src/lib.rs
@@ -4,6 +4,7 @@ use http_body_util::combinators::BoxBody;
use http_body_util::{BodyExt, Full};
use std::ffi::{CStr, CString};
use std::mem::MaybeUninit;
+use std::process;
use std::ptr;
use std::sync::OnceLock;
use tokio::sync::mpsc;
@@ -126,7 +127,7 @@ unsafe extern "C" fn start(
bindings::nxt_unit_run(unit_ctx);
bindings::nxt_unit_done(unit_ctx);
- Ok(())
+ process::exit(0x0);
})
}
Thanks for looking!
I've done a cursory test with this patch and at first glance it works as expected. I can cargo component build && unitc /control/applications/…/restart
with impunity.
Side note: it would be more convenient if libwasm_wasi_component.so was compiled with a _unit.so suffix so that it can be disovered without first renaming (or requiring make install
to do that).
I've done a cursory test with this patch and at first glance it works as expected. I can
cargo component build && unitc /control/applications/…/restart
with impunity.
I also replicated that the fix works. 👍
Side note: it would be more convenient if libwasm_wasi_component.so was compiled with a _unit.so suffix so that it can be disovered without first renaming (or requiring
make install
to do that).
I believe I ran into this too. Make doesn't appear pick up on changes to lib.rs.
I also replicated that the fix works. 👍
Thanks!, I'll add both your Tested-by:
's
Side note: it would be more convenient if libwasm_wasi_component.so was compiled with a _unit.so suffix so that it can be disovered without first renaming (or requiring
make install
to do that).
You have to really fight against cargo to get it named differently, we do that for macOS... I suppose we could do it for the others, but I'm not sure if there is any other practical differences between cargo build ...
and cargo rust ...
NXT_OS=$(uname -s)
if [ $NXT_OS = "Darwin" ]; then
NXT_CARGO_CMD="cargo rustc --release --manifest-path src/wasm-wasi-component/Cargo.toml -- --emit link=target/release/libwasm_wasi_component.so -C link-args='-undefined dynamic_lookup'"
else
NXT_CARGO_CMD="cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml"
fi
I believe I ran into this too. Make doesn't appear pick up on changes to lib.rs.
Heh, yes, a slightly different issue, but I also have that fixed. PR coming shortly...
If either of you want to test the latest version of the patch, particularly if you have arm64 hardware... I'm really interested in if the language module builds without error.
OK, I found an arm64 machine to test on and I suspected, it fails to build there...
According to the documentation I should be able to restart any application by making a
GET
request to the appropriate /control/applications/… API endpoint.This is not working for WebAssembly Components. The restart request is accepted but subsequent calls to the application timeout.
Here is my reproducer based on this simple hello world component.