根据Ecma TC39 第 53 次会议的议程，共享内存和原子将进入第 3 阶段。这意味着它们的 API 将被冻结。 因此，如果 WebAssembly 社区组的愿景与 TC39 的愿景不同，那么 7 月 26 日星期二可能成为对规范进行任何更改的最后期限。
ES 提案： https :
chicoxyzzy
所有5条评论
我的问题是：每个人都同意将该规范中的主线程限制复制到 WASM 吗？
taisel
于 2016-07-20
@chicoxyzzy ，这里有一个关于 sab+wasm 的冗长讨论： https :
@taisel ，现在我很迂腐，但仍然：“主线程限制”在技术上不是该规范的一部分。 该规范允许某些线程拒绝阻塞（根据实现选择的标准），并且显然该功能是由浏览器的主线程驱动的，但是在浏览器之外的其他设置中使用 JS+共享内存并不需要有那个限制。 我看不出 wasm 在任何不同的情况下如何。 此外，我可以看到某些类型的工人，如 SharedWorkers，使用共享内存，但不允许阻塞。
事实上，对于 TC39 来说，要求浏览器允许在主线程上阻塞不会导致任何结果，只会导致冲突，并且可能会危及整个共享内存提案的实现。 我们现在拥有的是对适合现有 Web 生态系统的语言和浏览器的相当保守的扩展。 我们知道代理可以解决一些问题； 我们知道“非对称”阻塞（worker 阻塞但主线程不阻塞）可以解决其他问题； 我们需要在这方面获得一些经验，以找出真正的痛点在哪里，然后我们才能看到如何解决这些问题。 在这个阶段，尝试在主线程上强制阻塞是核心选项。
lars-t-hansen
于 2016-07-20
@lars-t-hansen 是的，我重申了这个软限制以鼓励讨论。
我认为仍有一群人可能希望移植尽可能轻松，而且我不知道 WASM 委员会可能想要放弃多少让步。
taisel
于 2016-07-20
为了补充上述内容， Discussion.md 的 WebAssembly 部分对 sab+wasm 讨论进行了很好的总结。
sunfishcode
于 2016-07-26
最初的线程提议旨在匹配 SAB+workers 的行为，因此不太可能在这里摇摇欲坠。 我们已经讨论过拥有“纯 wasm”线程，它没有 JavaScript 上下文，但我们决定在我们达到与 JavaScript + SAB 的特性对等后更好地解决这个问题。
此外， html 规范现在已与 ES 规范WRT 阻塞Atomics.wait ）。
binji
于 2017-05-09
相关问题
cretz
·
5评论
konsoletyper
·
6评论
artem-v-shamsutdinov
·
6评论
ghost
·
7评论
aaabbbcccddd00001111
·
3评论
最有用的评论
@chicoxyzzy ，这里有一个关于 sab+wasm 的冗长讨论： https :
@taisel ，现在我很迂腐，但仍然：“主线程限制”在技术上不是该规范的一部分。 该规范允许某些线程拒绝阻塞（根据实现选择的标准），并且显然该功能是由浏览器的主线程驱动的，但是在浏览器之外的其他设置中使用 JS+共享内存并不需要有那个限制。 我看不出 wasm 在任何不同的情况下如何。 此外，我可以看到某些类型的工人，如 SharedWorkers，使用共享内存，但不允许阻塞。
事实上，对于 TC39 来说，要求浏览器允许在主线程上阻塞不会导致任何结果，只会导致冲突，并且可能会危及整个共享内存提案的实现。 我们现在拥有的是对适合现有 Web 生态系统的语言和浏览器的相当保守的扩展。 我们知道代理可以解决一些问题； 我们知道“非对称”阻塞（worker 阻塞但主线程不阻塞）可以解决其他问题； 我们需要在这方面获得一些经验，以找出真正的痛点在哪里，然后我们才能看到如何解决这些问题。 在这个阶段，尝试在主线程上强制阻塞是核心选项。