Apps with unyielding loops in goroutines hang on web

[kkoreilly]

Describe the bug

See #1407 (reply in thread), golang/go#65178, golang/go#60857.

How to reproduce

See #1407 (reply in thread).

Example code

No response

Relevant output

No response

Platform

macOS

[0pcom]

Another possible, though perhaps not practical solution is just to avoid the use of goroutines altogether. I had to do that for such webassembly animations which compile with tinygo because tinygo only supports single-thread usage.

Another perhaps more practical solution might be to use multiple wasm binaries. I do believe that they will execute on different threads but check me on that as I'm not 100% certain.

However, this will likely cause substantial increase in the size of the page resources, possibly doubling the total cumulative size of the wasm binaries. And it might be very complex for core to do that automatically from a source code file for a cogentcore application with core build web && core run web.

...

I opted for the latter approach for a similar globe animation + shopping cart wasm application (not a cogentcore application). When I split the code into two separate files and compiled them each to their own wasm binary, it removed the stutter from the animation which was introduced by the combined source code.

What was very strange in the case I just mentioned, even when other function calls were not executed, but included behind a function that blocked further execution - i.e.:

func main() {

blockingAnimation()

otherFunction()

}

the mere presence of the otherFunction() call - which never executed - caused the animation to stutter every few seconds. Commenting out the function call but leaving the function itself in the code avoided the stutter of the animation.

I have no explanation for that behavior, and it wasn't caused by a goroutine in this case.