Hacker News Reader

Comment by amelius | Hacker News Reader

Imho, the WebAssembly community should focus on the missing features multithreading and shared memory. That way, we could run arbitrary code, written in arbitrary languages, and we could just compile existing code to the platform without problems, saving lots of developer time.

View on HN

Good news! WebAssembly has community group projects setup for both multithreading [0] and multi-memories [1] which would allow a module to both define a memory space and also import a shared one.

There are so many parties interested in wasm, there are a ton of inflight proposals and extensions to get it beyond the mvp stage.

[0]: https://github.com/WebAssembly/threads [1]: https://github.com/WebAssembly/multi-memory

Where is this all being discussed and developed?

There is a W3C sponsored Community Group https://www.w3.org/community/webassembly/.

Development of the spec(s) happen in the open on the various github projects (https://github.com/WebAssembly/). Meeting notes, agendas, proposals, etc... are all kept as markdown in the git repositories.

Thanks!

Shared-memory multi-threading is only one piece of the puzzle though. A lot of existing code also depends on synchronous I/O (fopen, ...), or want to execute "long running loops", these are also currently not possible when running in a web browser context, at least not without hacks and workarounds.

Ideally, libraries should only use a very small subset of the POSIX / C-runtime APIs (ideally none which need to call into the underlying operating system), and provide ways for the library user to override this functionality, or not depend on those at all (simple example: allow to provide input data via memory instead of letting the library call into the C runtime I/O functions). Same for threading: instead of spawning threads inside the library, provide an API which takes "chunks of work", and let the library user care about doing this across multiple threads.

I agree to a point, but what if you wanted to port a virtual machine such as the JVM to WASM, which runs a concurrent garbage collector in the background. You can't really divide the process into "chunks of work" in that case, or only in a contrived way (starting the threads is not the issue), and you'd need the shared memory functionality to even make it work (the GC thread would need full access to the data in the other threads).

Reply on news.ycombinator.com