threads
threads copied to clipboard
WebAssembly
Coordinate WebAssembly memory model changes w/ ECMAScript (via TC39)
This is a tracking issue to coordinate the changes to the memory model we discussed in previous CG meetings w/ ECMAScript.
- Require 1- and 2-byte atomics to always be lock-free
- Remove
is_lock_free-- should this be removed from ES as well?
Are there others?
It's hard to remove things from ES. In this case it may be possible, since usage on the web is likely to be minuscule, but my money would be on it not happening.
Wasm dictating to ES which sizes should be lock free is a case of the tail wagging the dog. We've decreed that 8-byte atomics are lock free in Wasm but no amount of decreeing will make that true in reality on MIPS32; we've accepted that as the cost of doing business but TC39 might not. There's really no good reason why Atomics.isLockFree in ES should lie about it.
Agreed, I think the best way forward here is to see what TC39 thinks about this, then report the findings to the WebAssembly CG.
Does it actually affect interop which operations are lock-free on the other side?
Does it actually affect interop which operations are lock-free on the other side?
Wasm and JS have to agree on how to do this in the implementation. My point was merely that even though we require 8-byte lock-free atomics we can't have them on MIPS32 and the wasm implementation will just have to lie about that. But on the JS side I think Atomics.isLockFree(8) should probably return false in this case, to reflect reality.
A second concern is that user code that runs both wasm and JS and shares an atomic data structure between the two will have to use the same strategy in both types of code. So if the JS code uses isLockFree(8) and specializes the algorithm based on the result then it must propagate that information into wasm so that wasm can make the same specialization.
Does it actually affect interop which operations are lock-free on the other side?
Yes. Concretely it means that tearing can occur.
