ajwerner opened issue #9317:
Feature
wasmtime
today installs signal handlers that it uses to recover from traps that occur during the execution of a wasm program. This is very legit -- no problems there. The issue I have is that it appears that the signal handler installation throws away the existing signal handlers. That means if anybody else wants to interact with that signal, and, say, it occurs not when running wasm, they cannot. Instead, wasmtime should detect via some tls state whether the signal has occurred while inside a wasm call, and if not it should call through to the previous handler.Benefit
This will allow wasmtime to be used in applications which themselves have signal handlers for various faults.
Implementation
A global variable to store the next signal handlers to call and some logic to decide whether the signal occurred within wasm.
ajwerner closed issue #9317:
Feature
wasmtime
today installs signal handlers that it uses to recover from traps that occur during the execution of a wasm program. This is very legit -- no problems there. The issue I have is that it appears that the signal handler installation throws away the existing signal handlers. That means if anybody else wants to interact with that signal, and, say, it occurs not when running wasm, they cannot. Instead, wasmtime should detect via some tls state whether the signal has occurred while inside a wasm call, and if not it should call through to the previous handler.Benefit
This will allow wasmtime to be used in applications which themselves have signal handlers for various faults.
Implementation
A global variable to store the next signal handlers to call and some logic to decide whether the signal occurred within wasm.
ajwerner commented on issue #9317:
My mistake, got confused looking at https://github.com/bytecodealliance/wasmtime/blob/110e70f30e34b9df5ed4aaf401c8818c23204ca2/examples/min-platform/embedding/wasmtime-platform.c#L99-L119. It does the right thing! :tada:
Last updated: Nov 22 2024 at 17:03 UTC