Panic Recovery and Module Re-loadability

[cwfitzgerald]

Motivation

We are building a web app in rust that is designed to be a productivity tool with a large chunk of the code implemented in rust on wasm. As part of of this, we want to be robust to rust panics. Our rust wasm module is designed such that we can completely re-initialize the data if something were to go wrong. In practice though, this almost always leads to some kind of spooky behavior/UB because of the module-level globals generated by wasm-bindgen.

Proposed Solution

Our ideal solution would be some way to "clear" the wasm memory and any wasm-bindgen datastructures to that we can re-start our module with a fresh slate within the same session. In a similar way, having all the state as an object we can manage, as opposed to module-level globals, would be great.

Alternatives

Currently we tell the user to re-load the page, which is less than ideal. If there was some way to re-load modules in javascript, we could use that, but as far as I'm aware, caching will mean that all subsequent loads of a module will be the same as the original load. If there are other alternatives that I'm not aware of, do let me know!

Additional Context

Thank you for all the amazing work on wasm-bindgen and friends, it honestly keeps surprising me how well it works!

I tried to look for duplicate issues, but I didn't find any direct matches.

[daxpedda]

I am sympathetic to this problem and had to workaround it myself as well many times.

Generally speaking, I agree this should be possible and I would even be willing to implement it as its something I would need myself as well

However the first thing that comes to mind is that e.g. event listeners would not be removed and they would start throwing when attempting to call non-existing Wasm resources. So this would complicate things unless we intend to just let them throw.

Secondly, my assumption here is that this need is mostly caused by the lack of unwinding, otherwise the state could be recovered purely in Rust, but let me know if this doesn't apply to your use case!
If this is the case, we could address this issue by just implementing unwinding support in Walrus, as LLVM and Rust already supports the proposal (its old form anyway, which is what browsers implement as well).