-
Notifications
You must be signed in to change notification settings - Fork 895
-
Notifications
You must be signed in to change notification settings - Fork 895
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
Allow goroutines from exported wasm functions #3095
Comments
If you want to call an exported function without calling Or do you mean something else? It might be possible to allow calling exported functions after main has returned, if that is what you want. |
|
I don't think this can work, at least not in a JS environment. The issue is that JavaScript can't block, and you are doing a blocking operation with Apart from that, running goroutines after
In other words, goroutines that were running when main exits will be terminated. That doesn't necessarily imply that you can't start new goroutines, but it would be odd if that were possible. |
ok I should rephrase this as non-js. ex wasi and freestanding cc @hunjixin The nature of entry points in wasm are different than go, and the impedance mismatch is a reality. what we do about it however is our choice. IOTW saying something about how main works in normal go, is historical context, but in the context of wasm (non js.. remember wasm core spec has no JS in it), it isn't necessarily painting a clear decision of what to do. |
Does this boil down to #2735 ? |
I'm not really sure the future of the reactor thing in WASI, even normal command is being completely redone. It feels uncomfortable to move it to blocked on something we don't implement, and might be dead by the time we do.. |
I encountered a very similar problem with wasm ran in the browser. Rather than panic, the goroutine would just not execute. I was able to "fix" it by wrapping it in a js func: var work = js.FuncOf(somethingThatUsesGoroutines)
//export notMain
func notMain() {
work.Invoke()
} |
Currently, the following will work as expected:
However, doing the same from an exported function besides main panics at the line the goroutine is created.
Since Wasm isn't parallel-safe, we rely on keeping main alive and calling the exported function at the same time.
It would seem helpful to have a compiler flag or an annotation like
//enable-scheduler
Note: jimmysl lee noticed that if you manipulate the
%.wasm
and insert acall
opcode to call the_start
function prior to actually invoking the desired export, it doesn't crash. This hint might help narrow down a path to a solution.The text was updated successfully, but these errors were encountered: