As discussed in #455 (comment), the concept of "externally aliasable" modules has unclear implications on WebAssembly's memory model.
In C++ it's a bit of a fiasco to use shared memory:
volatile should be used to denote external modification, so the compiler remains conservative.std::atomic should be used to enforce ordering and no-tear (yes, in addition to volatile).- Non-lock-free
atomics are guaranteed to work in an address-free way within the same process but definitely do not work when using shared memory across processes.
This makes me wary of specifying things as outlined in Module.md by #455 without properly understanding what this implies for threads in WebAssembly as well as what it implies for the embedder (e.g. on the web what does this mean for SharedArrayBuffer). Does it entirely prevent optimizations? Valid reordering? 64-bit atomics on some platforms?
Note that "externally aliasable" is a very desirable feature to reduce the amount of copying and to expose idiomatic APIs to WebAssembly.
We don't need to tackle this now, but we need to make sure MVP doesn't over-constrain us. Let's revisit before MVP.
As discussed in #455 (comment), the concept of "externally aliasable" modules has unclear implications on WebAssembly's memory model.
In C++ it's a bit of a fiasco to use shared memory:
volatileshould be used to denote external modification, so the compiler remains conservative.std::atomicshould be used to enforce ordering and no-tear (yes, in addition tovolatile).atomics are guaranteed to work in an address-free way within the same process but definitely do not work when using shared memory across processes.This makes me wary of specifying things as outlined in
Module.mdby #455 without properly understanding what this implies for threads in WebAssembly as well as what it implies for the embedder (e.g. on the web what does this mean for SharedArrayBuffer). Does it entirely prevent optimizations? Valid reordering? 64-bitatomics on some platforms?Note that "externally aliasable" is a very desirable feature to reduce the amount of copying and to expose idiomatic APIs to WebAssembly.
We don't need to tackle this now, but we need to make sure MVP doesn't over-constrain us. Let's revisit before MVP.