Use Web Workers for true concurrency

[JohnStarich]

The biggest performance bottleneck for hackpad right now appears to be true parallelization. The Go CLI performs starts compile and link processes, which could benefit greatly with real parallelization and moving off of the main thread (even though they run in the background).

Going further, I think it could make sense to set up the kernel as a single SharedWorker, with each browser tab representing a new abstract "worker" concept that can run processes. Each tab would start by registering itself as a worker and "requesting" an editor be spawned on itself. Using a single kernel would keep overhead much lower, and enable some interesting inter-tab and project behaviors.

Moving from a single main/background thread to multi-worker is a big undertaking, so this could take a while.

[gedw99]

Have you seen go-app?

https://github.com/maxence-charriere/go-app

it uses web workers

[gedw99]

https://github.com/realPy/hogosuru/blob/main/broadcastchannel/broadcastchannel.go#L4 might help !

Been using all of this code with gio: https://github.com/realPy/hogosuru/issues/36

[JohnStarich]

FYI I've made some progress with Workers, though it's been slow-going. MessagePorts are great, but they sure are hard to debug when they're inside the runtime.

I think after this is implemented, I might reorganize everything – I can only name so many different objects "worker," "process," and "filesystem" before I start going crazy 🙃

[JohnStarich]

Thanks for the contributions @gedw99 You're awesome 😄

[gedw99]

looking forward to seeing this.

I am trying to use services workers, and to also have the exact same things running outside WASM. SO match the Service workers spec, to build a golang proxy, just like Service workers.

This will allow the same golang wasm to run inside a browser, as well as on any other device.

[gedw99]

I think after this is implemented, I might reorganize everything – I can only name so many different objects "worker," "process," and "filesystem" before I start going crazy 🙃

If oyu have a branch or code to look at even if its in bad shape, let me know. It will be interesting to me for my work in matching the Browser environment in a non browser environment.

[JohnStarich]

@gedw99 Definitely. Current progress is now pushed up as #18

[gedw99]

Thanks 🙏 @JohnStarich for the heads up.

is it ok if I wait until it’s finished as it’s holidays here and I am trying to avoid work stuff as much as possible

[JohnStarich]

No worries! I'm slowly attacking the problem bit by bit, eventually we'll get it done 😄

[paralin]

Building parallelized programs w/ Go in the browser w/ WebWorkers is one of the goals of ControllerBus: https://github.com/aperturerobotics/controllerbus

There's a lot of time invested towards building modular pluggable programs in that repo, communicating via IPC over MessageChannel. It could be useful for this purpose.

[JohnStarich]

Interesting. Thanks for sharing @paralin

[JohnStarich]

This problem has been haunting me for quite some time 🙂 I'm still working on it, though progress remains slow. A new implementation has been pushed. This one crashes less and the design is slightly improved.

Just need to figure out these silly crashes. The traces are incredibly unhelpful 🤔

[JohnStarich]

Made some good progress. Finally found and fixed a callback blocking the event loop which triggered a crash loop.

Now, onto making pipes work across MessageChannels!

[JohnStarich]

Finally have the draft PR working with web workers 🎉 Still have some issues with stdin/stdout on the terminal, but this refactor is nearly done!

The next major part after web workers is attempting to parallelize the calls to the compile and link tools. The compiler seems to be avoiding them at the moment, though I'm not sure I understand it yet. I might be hitting transaction throughput issues in IndexedDB.

[oliverlj]

In our project, we used postMessage to communicate with a web worker. https://gitlab.com/c1560/cryptofiscafacile/-/blob/develop/wasm/src/wasm-worker-proxy.ts

[amlwwalker]

@JohnStarich any luck on this? This seems like the big refactor that this project needs and last update sounded positive!