Web workers were on my mind from the start but I never found myself needing them. They were always my ace-in-the-hole if this ended up being too CPU hungry on the main thread but it never happened, so I didn’t bother.

One of the fun things is it shouldn’t be too difficult to create a new RuntimeService that uses web workers and slots in alongside my existing CRI. I’d love a PR along those lines!

▲

tekacs 4 hours ago | parent [-]

I definitely don't think that ordinary things would be too CPU-hungry on the main thread, but given how awkward it _can_ be to use the worker APIs, it would be a lovely abstraction to be able to treat workers as pods. I would love to run a CPU-hungry or WASM service on a worker as a pod and communicate with it over your take on CNI!

Similarly, when you move on to doing Volumes support, the browser's OPFS APIs can be synchronous from workers and only async from the main thread, so there are interesting possibilities around buffering/caching/using SharedArrayBuffer to accept-and-write extents that could be nice with workers. :)

If I get a spare moment, I'll absolutely take a look at PR-ing a runtime!

▲

samwho 4 hours ago | parent [-]

I’m 100% confident it would be possible to do a worker-per-pod runtime. If you’re serious about trying to make it then slide into my DMs, would love to talk about it. I also think a CRI that supports WASM would be fairly easy.

Volumes are one of those things that I’m quite sure won’t be that difficult to implement but I don’t have a need for them in the near future, so likely won’t support them for a good while.

	▲	tekacs an hour ago \| parent [-]
		DM-ed :)