WASI: remove __wasi_proc_raise() #68
Labels
wasi:api
Issues pertaining to the WASI API, not necessarily specific to Wasmtime.
Comments
sunfishcode
added
the
wasi:api
|
Yeah, If proper signal-handling is ever to be supported, it will depend on new features being added to the core WebAssembly spec. That may happen some day, but on the WASI side there's nothing to do until then. |
|
Continuing the discussion at WebAssembly/WASI#7. |
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this issue
May 12, 2023
* Update wasmtime and wit-bindgen This commit updates the `wasmtime` dependency and the `wit-bindgen-guest-rust` dependencies to namely update the `wit-parser` and component underlying implementations. This pulls in bytecodealliance/wasm-tools#867 which is the implementation of `use` for WIT. This does not currently break apart the one large `wasi.wit` file, instead just gets tests working. * Split apart `wasi.wit` into multiple `*.wit` files This commit refactors the monolithic `wasi.wit` file into multiple files. I've taken some liberties in naming here so suggestions are definitely welcome! I've resolved some TODO annotations as well about `use`-ing types between interfaces. There are two issues remaining, however: * The `wasi-command` world still hardcodes `u32` because `world` items don't support `use` just yet. That isn't a hard limitation of WIT, however, it's just a temporary limitation of the implementation. * The `wasi-clocks` interface defines the `wasi-future` type. This is due to a cyclic dependency where `wasi-future` is defined within `wasi-poll` which depends on `wasi-clocks` for types. I've left this to a future refactoring to probably have a `types` interface of some form somewhere. * Update patch for wasm-tools * Switch to wasmtime upstream * Update CI for build * Remove patch overrides * Update names of uploaded files
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this issue
May 16, 2023
* Update wasmtime and wit-bindgen This commit updates the `wasmtime` dependency and the `wit-bindgen-guest-rust` dependencies to namely update the `wit-parser` and component underlying implementations. This pulls in bytecodealliance/wasm-tools#867 which is the implementation of `use` for WIT. This does not currently break apart the one large `wasi.wit` file, instead just gets tests working. * Split apart `wasi.wit` into multiple `*.wit` files This commit refactors the monolithic `wasi.wit` file into multiple files. I've taken some liberties in naming here so suggestions are definitely welcome! I've resolved some TODO annotations as well about `use`-ing types between interfaces. There are two issues remaining, however: * The `wasi-command` world still hardcodes `u32` because `world` items don't support `use` just yet. That isn't a hard limitation of WIT, however, it's just a temporary limitation of the implementation. * The `wasi-clocks` interface defines the `wasi-future` type. This is due to a cyclic dependency where `wasi-future` is defined within `wasi-poll` which depends on `wasi-clocks` for types. I've left this to a future refactoring to probably have a `types` interface of some form somewhere. * Update patch for wasm-tools * Switch to wasmtime upstream * Update CI for build * Remove patch overrides * Update names of uploaded files
mooori
pushed a commit
to mooori/wasmtime
that referenced
this issue
Dec 20, 2023
dhil
added a commit
to dhil/wasmtime
that referenced
this issue
Dec 30, 2023
Weekly merge with upstream. This merge was rather odd as several failures related to stack traces began occurring. The changes all seem to be orthogonal; the only conflict was the versioning of `windows-sys` in `Cargo.lock`. After resolving the merge conflicts by hand rather than regenerating the `Cargo.lock`, the failures seem to have disappeared, making me believe the failures are related to the exact version of `windows-sys`. Occasionally I would observe `cargo test` stopping prematurely with ``` Caused by: process didn't exit successfully: `/home/dhil/projects/wasmfx/wasmtime/target/debug/deps/all-2197ac4314cc5afd` (signal: 11, SIGSEGV: invalid memory reference) ``` This failure is seemingly due to the test `unhandled.wast`. It exposes a problem with trap generation and propagation in the presence of linked stacks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please remove
__wasi_proc_raise()from WASI core. If signals are going to be supported, they need to be in a module. Some implementations may choose not to support signals at all.The text was updated successfully, but these errors were encountered: