Ben Smith

I tried this in a small example in Chrome, and I was able to create ~40 Workers, post modules to them and instantiate before it started running out of memory....

> any program that shares a memory between multiple modules will need a memory that JS will be able to observe. So aligning with JS is likely inevitable. Perhaps, though...

Agreed that these instructions are very large, but they're likely to be relatively rare in the module. I'd be curious to see how often they occur in real modules.

Side comment for those who may be following the issues but didn't read the CG meeting notes: We agreed that native threads are not required for the v1 thread proposal.

> With the current proposal, setting up a threaded application requires a fair bit of JS glue... Agreed, but reusing workers is a simpler target than adding native threads, and...

> And PNaCl would also need to follow COOP and COEP. It's not about messaging or SharedArrayBuffer, it's about any sort of multithreading. I'm not sure about that -- PNaCl...

I believe I added this at the suggestion of @jfbastien, perhaps he can explain the rationale for these lines.

Yeah, I was writing it as all-or-nothing in the bulk memory spec to match the current behavior, with the assumption that the threads spec would change it. But you're right,...

@lachlansneff yes, we discussed doing something similar to what you've described here. However, the current proposal was designed to be as similar as possible to what is currently available in...

Yes, as mentioned in that bug, creating a Worker is heavyweight, so we would like to have a lightweight native threading primitive for wasm. That said, the design and implementation...