Hood Chatham

> maybe it's a matter of having another backend that would work in a web worker This is a TODO. Would you mind opening an issue for it?

Hi @stefnotch, very interested in your feedback. I am close to a working prototype implementation of a system that would provide really tight worker integration. It'll probably take quite a...

Thanks for the excellent summary of the state of affairs @stefnotch. The solutions are indeed complex, and it would be good to have some first party options. Because the solutions...

> I suppose the next-best alternative might be something along the lines of: 'Import this into your worker, then make sure to call that function and pass it a callback....

> If you need any assistance or feedback, I'm always glad to help where I can. Yeah these conversations are quite helpful already. > writing Python code should be as...

> a slightly more advanced, promise-based API IMO the most important aspect is a synchronous API with explicit control over job dispatch and an explicit command to block for completion.

I am interested, please do explain. There are of course two separate issues here: (1) Is it possible? (2) Is it a good idea?

> Essentially, this would be recreating comlink Yeah we need to have our own special-purpose version of comlink which is going to diverge from upstream comlink right away.

Okay so this sounds broadly like what I would expect. You have improved on some things in my approach and unimproved on other things. I think we have done a...

One long term design consideration is how this will interact with `WASM_PTHREADS`. I think the design we are discussing is actually better in many ways than `WASM_PTHREADS`. The main limitation...