How to abort

[dschuff]

Currently emscripten's implementation of abort() calls to JS (where it calls some user hooks and collects a stack trace) and throws an exception, allowing it to propagate through all the wasm frames out to the caller.

Once we have wasm exceptions, that probably won't be what we want, because foreign exceptions unwinding through wasm frames will cause destructors to run, which isn't what we want for abort (and it may eventually be the case that in some configurations C++ catch(...) clauses may catch foreign exceptions). We need some other way to abort.

One straighforward option could be to export a wasm function that executes unreachable. IIUC with MVP wasm that would be functionally the same, but I don't know if anywhere in emscripten's runtime actually tries to catch or check an abort. Also the issue of traps vs exceptions isn't 100% settled yet but it will certainly be the case that the wasm code will ensure that traps do not cause destructor execution.

It's a little unfortunate to have to export an extra function, but it would be nice to have the same API for EH and non-EH builds.

Any ideas I'm missing?

[dschuff]

/cc @aheejin

[aheejin]

+1 on implementing abort in wasm and exporting it. abort implementation in wasm will trap and it will become a RuntimeError in JS, so the MVP functionality would be the same. I'm planning to propose not to catch traps in the new EH proposal after all, because we need something that's uncatchable to implement abort.

[kripken]

Could we do

throw WebAssembly.RuntimeError('abort')

in JS? Seems like that would show up as a RuntimeError in the wasm unwinding, and be handled properly. The benefit to doing it from JS is that we need to set up some state on the JS side too (set the global ABORT so we know we can stop running any more code, like setTimeouts for the future), and also this would be basically a one-line change instead of reworking what's imported or not.

[aheejin]

Yeah that would be even better!