Add note on emscripten_set_main_loop with Wasm EH #16871
Conversation
When `simulate_infinite_loop` is true, `emscripten_set_main_loop` does not work with the new Wasm EH because throwing a JS exception will cause destructors in the Wasm stack frames to run. This can be fixed in future by either by fixing the LLVM compilation by adding an additional `catch` to every `catch_all` so that we can rethrow JS exceptions of this kind, or possibly using the new stack switching proposal. This PR adds a note that this features currently doesn't work with Wasm EH.
|
This is rather unfortunate... given that it doesn't work can we assert at runtime if this flag is passed? Or at least write a warning the console? I guess it only really matters if you have C++ object in your stack when you call it so many users (e.g SDL games who call this from |
| .. note:: Calling this function overrides the effect of any previous calls to :c:func:`emscripten_set_main_loop_timing` in the calling thread by applying the timing mode specified by the parameter ``fps``. To specify a different timing mode for the current thread, call the function :c:func:`emscripten_set_main_loop_timing` after setting up the main loop. | ||
| .. note:: Currently, ``simulate_infinite_loop`` == true does not work yet with `the new Wasm exception handling <https://emscripten.org/docs/porting/exceptions.html#webassembly-exception-handling-proposal>`_; your program may crash with memory errors. |
There was a problem hiding this comment.
Perhaps mention "does not work in C++ projects that have objects with destructors on the stack at the time of the call"?
I think you're right; if you don't have any destructors to run this will work fine. So if you only call this from the main without any stack-allocated objects this should be fine. So I'm not sure if we should assert... maybe a warning is enough? (Then where should we warn? Inside |
3 participants
When
simulate_infinite_loopis true,emscripten_set_main_loopdoesnot work with the new Wasm EH
because throwing a JS exception will cause destructors in the Wasm stack
frames to run. This can be fixed in future by either by fixing the LLVM
compilation by adding an additional
catchto everycatch_allso thatwe can rethrow JS exceptions of this kind, or possibly using the new
stack switching proposal.
This PR adds a note that this features currently doesn't work with Wasm
EH.