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.

[kkoreilly]

@0pcom Thank you for the ideas. Although it is not possible to completely remove goroutines at this time, your idea did give me an idea for how to fix this. Instead of using a separate ad-hoc goroutine for the render loop of a canvas, we will add an OnWindowPaint or similar function, which will allow you to inject functions that occur each time the window is supposed to be rendered, at a 60 FPS rate. That will allow you to accomplish the same functionality without needing a separate goroutine, which will prevent this hanging. (Critically, the main window paint event system that everything depends on has event compression so that it never gets behind on ticks like this).

I will implement and document that when I have the time to do so.

Please also note that #1429 is the long-term complete solution to issues like this.