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
chicoxyzzy
All 5 comments
My question is: Is everyone OK with copying the main thread limitations in that spec over to WASM?
taisel
on 20 Jul 2016
@chicoxyzzy, there was a longish discussion about sab+wasm here: https://github.com/tc39/ecmascript_sharedmem/issues/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.
lars-t-hansen
on 20 Jul 2016
@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.
taisel
on 20 Jul 2016
To add to the above, Discussion.md's WebAssembly Section has a good summary of the sab+wasm discussion.
sunfishcode
on 26 Jul 2016
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).
binji
on 9 May 2017
Related issues
beriberikix
路
7Comments
mfateev
路
5Comments
bobOnGitHub
路
6Comments
konsoletyper
路
6Comments
cretz
路
5Comments
Most helpful comment
@chicoxyzzy, there was a longish discussion about sab+wasm here: https://github.com/tc39/ecmascript_sharedmem/issues/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.