Shared memory and atomics

[chicoxyzzy]

According to Agenda for the 53rd meeting of Ecma TC39 Shared memory and atomics are going to stage 3. That means that their API will be frozen. So Tuesday, 26 July could become a deadline to make any changes in spec in case if WebAssembly Community Group vision differs with TC39 vision.

ES proposal: https://github.com/tc39/ecmascript_sharedmem

[taisel]

My question is: Is everyone OK with copying the main thread limitations in that spec over to WASM?

[lars-t-hansen]

@chicoxyzzy, there was a longish discussion about sab+wasm here: tc39/proposal-ecmascript-sharedmem#59

@taisel, now I'm being pedantic, but still: The "main thread limitations" are not technically part of that spec. The spec allows for some threads to decline to block (by criteria chosen by the implementation), and clearly that facility is motivated by the browsers' main threads, but a use of JS+shared memory in another setting than the browser does not need to have that limitation. I don't see how wasm is in any different situation. Furthermore, I could see some kinds of workers, like SharedWorkers, using shared memory, but not being allowed to block.

Indeed, for TC39 to require browsers to allow blocking on the main thread would not lead to anything fruitful, only to strife, and would probably endanger implementation of the entire shared memory proposal. What we have now is a fairly conservative extension to the language and the browsers that fits into the existing web ecosystem. We know proxying can solve some problems; we know "asymmetric" blocking (workers block but the main thread does not) can solve other problems; we need to get some experience with this to find out where the true pain points are, and then we can see how to address those. Trying to enforce blocking on the main thread is the nuclear option, at this stage.

[taisel]

@lars-t-hansen Yup, and I re-iterated that soft limitation to encourage the discussion.

There's still a group of people I thought might want porting to be as painless as possible, and I don't know many concessions the WASM committee might want to throw their way.

[sunfishcode]

To add to the above, Discussion.md's WebAssembly Section has a good summary of the sab+wasm discussion.

[binji]

The initial threading proposal is designed to match the behavior of SAB+workers, so is unlikely to rock the boat here. We've talked about having "pure wasm" threads, which do not have a JavaScript context, but decided that was better tackled after we reach feature parity w/ JavaScript + SAB.

In addition, the html spec has now integrated with the ES spec WRT blocking. It is now specified that currently only DedicatedWorker and SharedWorker can block (e.g. call Atomics.wait).