Stream: git-wasmtime

Topic: wasmtime / issue #5257 Wasmtime C API: Missing way to ret...


view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2022 at 22:43):

kpreisser opened issue #5257:

Hi!

As far as I understand the trap redesign with #5149, host traps/errors created with wasmtime_trap_new, as well as traps caused by setting the WASI exit code (by calling WASI's proc_exit), are now returned as wasmtime_error_t* instead of wasm_trap_t* (e.g. with wasmtime_func_call and wasmtime_linker_instantiate); whereas only actual WASM traps that have a corresponding trap code (wasmtime_trap_code_t) are still returned as wasm_trap_t*.

With #5215, the WASI exit code can now be retrieved from the wasmtime_error_t*.

However, the unchecked variant wasmtime_func_call_unchecked only returns a wasm_trap_t*, but no wasmtime_error_t*. Therefore, it doesn't seem possible e.g. to extract the WASI exit code from it:
https://github.com/bytecodealliance/wasmtime/blob/95ca72a37ae17d33d6fa727150dab5a49011b555/crates/c-api/include/wasmtime/func.h#L244-L248

Would this require an adjustment of the C API? E.g., should wasmtime_func_call_unchecked additionally return a wasmtime_error_t*, for consistency with wasmtime_func_call, so that it would return host traps and WASI exit traps as wasmtime_error_t*, instead of wasm_trap_t*?

Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2022 at 23:24):

kpreisser edited issue #5257:

Hi!

As far as I understand the trap redesign with #5149 regarding the C API, host traps/errors created with wasmtime_trap_new, as well as traps caused by setting the WASI exit code (by calling WASI's proc_exit), are now returned as wasmtime_error_t* instead of wasm_trap_t* (e.g. with wasmtime_func_call and wasmtime_linker_instantiate); whereas only actual WASM traps that have a corresponding trap code (wasmtime_trap_code_t) are still returned as wasm_trap_t*.

With #5215, the WASI exit code can now be retrieved from the wasmtime_error_t*.

However, the unchecked variant wasmtime_func_call_unchecked only returns a wasm_trap_t*, but no wasmtime_error_t*. Therefore, it doesn't seem possible e.g. to extract the WASI exit code from it:
https://github.com/bytecodealliance/wasmtime/blob/95ca72a37ae17d33d6fa727150dab5a49011b555/crates/c-api/include/wasmtime/func.h#L244-L248

Would this require an adjustment of the C API? E.g., should wasmtime_func_call_unchecked additionally return a wasmtime_error_t*, for consistency with wasmtime_func_call, so that it would return host traps and WASI exit traps as wasmtime_error_t*, instead of wasm_trap_t*?

Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2022 at 23:25):

kpreisser edited issue #5257:

Hi!

As far as I understand the trap redesign with #5149 regarding the C API, host traps/errors created with wasmtime_trap_new, as well as traps caused by setting the WASI exit code (by calling WASI's proc_exit), are now returned as wasmtime_error_t* instead of wasm_trap_t* (e.g. with wasmtime_func_call and wasmtime_linker_instantiate); whereas normally only actual WASM traps that have a corresponding trap code (wasmtime_trap_code_t) are still returned as wasm_trap_t*.

With #5215, the WASI exit code can now be retrieved from the wasmtime_error_t*.

However, the unchecked variant wasmtime_func_call_unchecked only returns a wasm_trap_t*, but no wasmtime_error_t*. Therefore, it doesn't seem possible e.g. to extract the WASI exit code from it:
https://github.com/bytecodealliance/wasmtime/blob/95ca72a37ae17d33d6fa727150dab5a49011b555/crates/c-api/include/wasmtime/func.h#L244-L248

Would this require an adjustment of the C API? E.g., should wasmtime_func_call_unchecked additionally return a wasmtime_error_t*, for consistency with wasmtime_func_call, so that it would return host traps and WASI exit traps as wasmtime_error_t*, instead of wasm_trap_t*?

Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 14 2022 at 15:18):

alexcrichton commented on issue #5257:

Oh dear you are right, thanks for the report! I'll work on updating this API today to return the error/trap combo. I think the error/trap combo probably needs to be redone in the future since it makes less sense than it did before, but in the meantime no functionality should be lost with this prior refactoring.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 14 2022 at 18:30):

alexcrichton closed issue #5257:

Hi!

As far as I understand the trap redesign with #5149 regarding the C API, host traps/errors created with wasmtime_trap_new, as well as traps caused by setting the WASI exit code (by calling WASI's proc_exit), are now returned as wasmtime_error_t* instead of wasm_trap_t* (e.g. with wasmtime_func_call and wasmtime_linker_instantiate); whereas normally only actual WASM traps that have a corresponding trap code (wasmtime_trap_code_t) are still returned as wasm_trap_t*.

With #5215, the WASI exit code can now be retrieved from the wasmtime_error_t*.

However, the unchecked variant wasmtime_func_call_unchecked only returns a wasm_trap_t*, but no wasmtime_error_t*. Therefore, it doesn't seem possible e.g. to extract the WASI exit code from it:
https://github.com/bytecodealliance/wasmtime/blob/95ca72a37ae17d33d6fa727150dab5a49011b555/crates/c-api/include/wasmtime/func.h#L244-L248

Would this require an adjustment of the C API? E.g., should wasmtime_func_call_unchecked additionally return a wasmtime_error_t*, for consistency with wasmtime_func_call, so that it would return host traps and WASI exit traps as wasmtime_error_t*, instead of wasm_trap_t*?

Thanks!


Last updated: Oct 23 2024 at 20:03 UTC