wasm: scheduling of JavaScript callbacks is not fair #27894
Comments
|
Is this in some way related to #26045? |
|
Possibly. But I am not very clear on what exactly this issue tries to resolve. Does Otherwise, I don't see a reason other goroutines will still wait for a callback from js. |
|
The issue I am seeing here is not that go-routines cannot run while we wait for a callback, but that callbacks do not happen until no other go-routine runs. I just briefly looked at the runtime and might have missed something. But this is how I understand it: Go (running on top of WebAssembly) can only receive callbacks from JavaScript if the WebAssembly runtime returns to the event loop. This is facilitated by pauseSchedulerUntilCallback, which in the go-runtime for JavaScript calls pause if any callbacks from JavaScript are potentially pending, that is a callback handler has been registered before. I looked at Line 148 in 50bd1c4 The call to pause will fully unwind the stack and return from WebAssembly back to JavaScript land. Line 72 in 50bd1c4 Is there another path to fully unwind and return to JavaScript that I have missed? |
katiehockman
changed the title
katiehockman
added
the
NeedsInvestigation
|
/cc @neelance |
|
Yes, giving back execution from Go (WebAssembly) to JavaScript is a "stop the world" action for Go. No goroutine will run until a callback invokes Go code (user action, timer, etc.). Since we want all Go code to run which is not waiting for such callbacks, we give back execution to JS only if ALL goroutines are asleep. If your Go code always has something to do, execution will never be passed back to JS, so user events will not be processed. This is the current situation. Maybe we could extend the scheduler so it periodically gives back execution to JS, even if there are still runnable goroutines. This somewhat depends on #26045. |
|
I think this needs further work. Most likely it will get resolved when we add WebAssembly threads. |
|
@neelance I think I'm running into this same issue, but I'm a bit confused by your explanation. How are goroutines scheduled in the browser environment? If there are 3 pending goroutines, does this equate to 3 pending events in the event queue? If it does, shouldn't an I/O event simply take its place in the event queue after the pending goroutines? |
|
No, goroutines are not mapped to the event queue. If there are still goroutines awake, then the event queue will not get processed. |
|
Thanks for responding! What constitutes "awake"? If one goroutine is blocked on a channel read and another is sleeping via |
Yes, if there is no other goroutine. |
What version of Go are you using (
go version)?go version go1.11 linux/amd64
Does this issue reproduce with the latest release?
yes
Description
I ran the webassembly benchmark in https://djhworld.github.io/post/2018/09/21/i-ported-my-gameboy-color-emulator-to-webassembly/ and as also noted on that page, the benchmark does not properly process keyboard input on chrome. See https://bugs.chromium.org/p/v8/issues/detail?id=8227 for the v8 tracking bug.
Due to a performance issue in v8, the compiled go code runs slower in v8 than firefox. As a consequence, there is more pressure on the go scheduler. In particular, there is nearly always a go-routine ready to be executed with very few idle pauses. Looking at the scheduler implementation at
go/src/runtime/proc.go
Line 2368 in eae5fc8
this leads to starvation of the go-routines that are waiting for a callback from java-script. In case of the gameboy emulator, this means that no more I/O events are being processed.
The text was updated successfully, but these errors were encountered: