jfbastien
commented
6 years ago C++ supports multiple memories, a.k.a. segments, through allocators 🙃 LLVM's IR also has support for it.
But I get your point: we'd need a toolchain championing this before we standardize.
This is not an "issue" for the current proposal, more of a remark, but curious if people see any use for it.
With the current proposal, the way a multi-threaded C++ program would typically be represented is a single shared linear memory and multiple instances of a module, since a C++ compiler can't separate shared memory from non-shared.
But there are advantages if a language front-end would be able to separate shared memory from non-shared (once we have support for multiple memories in an instance). The default one could be non-shared, with 1 or more additional shared memories.
It would improve safety/stability, since you can now guarantee all that non-shared memory cannot be trampled upon by other threads, allowing wasm to effectively help you isolate threading issues.
It could also help speed, since any run-time functions (such as e.g. a memory manager) can be specialized to non-multi-threaded versions. In C++ currently that is all or nothing, and seems to default to supporting multi-threaded for most compilers even in mostly single-threaded programs.
The problem is of course lack of languages that currently support this.