Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement recover for wasm architecture #2914

Open
Vilsol opened this issue Jun 16, 2022 · 6 comments
Open

Implement recover for wasm architecture #2914

Vilsol opened this issue Jun 16, 2022 · 6 comments
Labels
enhancement New feature or request wasm WebAssembly

Comments

@Vilsol
Copy link

Vilsol commented Jun 16, 2022

recover was implemented for most architectures in #2331, however wasm was left out.

As suggested here

tinygo/compiler/defer.go

Lines 29 to 33 in 4c64784

case "wasm32":
// Probably needs to be implemented using the exception handling
// proposal of WebAssembly:
// https://github.com/WebAssembly/exception-handling
return false
it should probably utilize the proposed exception handling: https://github.com/WebAssembly/exception-handling

Opened as per expected closure of #891

@Vilsol Vilsol changed the title Implement recover for wasm architecture Implement recover for wasm architecture Jun 16, 2022
@Vilsol Vilsol changed the title Implement recover for wasm architecture Implement recover for wasm architecture Jun 16, 2022
@deadprogram deadprogram added enhancement New feature or request wasm WebAssembly labels Jun 17, 2022
@codefromthecrypt
Copy link
Contributor

codefromthecrypt commented Sep 12, 2022

Few points which could lead to a better description and possibly another way out.

Summarizing the technical concern

There are a mix of opinions and technical concerns in the 60+ comments in the PR preceding this. It would be nice to have a summary here about what is a technical constraint vs a cultural disinterest in defer.

blocking on incomplete WebAssembly proposals

While some land faster than others, blocking on WebAssembly proposals can prevent implementation for periods of a year or more. The good news is that the proposal mentioned here is at least in phase 3, so it is more likely a when vs if, though it is possible still to be canceled before "finished".

https://github.com/WebAssembly/proposals

How do others get by?

I tried the test data in normal go GOARCH=wasm GOOS=js and it works, all the defer cases. A quick point on why it works in Go and why it working there has no impact to the design here could help.

@atdiar
Copy link

atdiar commented Sep 12, 2022

To add a use-case, when compiling with the go compiler, it allows us to recover from panics by displaying a relevant message in the browser.

@aykevl
Copy link
Member

aykevl commented Sep 14, 2022

I tried the test data in normal go GOARCH=wasm GOOS=js and it works, all the defer cases. A quick point on why it works in Go and why it working there has no impact to the design here could help.

You are correct, but note that the Go toolchain emits very different WebAssembly than TinyGo does. And as a result, TinyGo often makes much smaller binaries. I haven't really looked into how it works to be honest, but can't think of a way to implement recover without many changes to the compiler for a feature that is going to be relatively short-lived (the exception handling proposal is certainly the better way to implement recover).

We implemented goroutines using a big giant hack called Asyncify. We can maybe do the same for defer/recover, although the cost/benefit ratio seems far higher for recover.

While some land faster than others, blocking on WebAssembly proposals can prevent implementation for periods of a year or more. The good news is that the proposal mentioned here is at least in phase 3, so it is more likely a when vs if, though it is possible still to be canceled before "finished".

While frustrating, I think this is the most reasonable way forward. Correct me if I'm wrong, though. I'd love to have recover properly supported on all platforms.
If you want to speed this up, please try to get exception handling implemented in wasmtime because that's an important VM that doesn't support it yet: bytecodealliance/wasmtime#3427
There is also wasmer that also lacks support: wasmerio/wasmer#3100

@magic-akari
Copy link

Hi there, I'm reaching out to kindly inquire if there have been any recent developments or updates regarding this matter.

Considering that we're now in 2024 and exception handling is nearly a standard feature in mainstream browsers, I'm curious to know if there have been any changes or advancements in TinyGo's implementation of recover for the WASM target.

Thank you for your attention to this, and I look forward to any information you can provide.

@abourget
Copy link

Got caught by a recover call too.. do you guys have an idea if/when this would be solved?

@aykevl
Copy link
Member

aykevl commented Aug 4, 2024

I have implemented recover for WebAssembly. I'll need to clean up the code and then I can make a PR.
But note:

EDIT: see #4380

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wasm WebAssembly
Projects
None yet
Development

No branches or pull requests

7 participants