如何评价 Webkit 推出的并发 JavaScript 提案？ 第1页

谢邀。【唉，吃个生日蛋糕也不省心，被硬邀读这么硬的文章，而且那些细节好艰深……R大救我！还要评价，我要立了 flag，万一以后 thread 真进了 ES 标准，不是被打脸嘛……算了，反正我皮厚。】

目前应该还不是正式的提案，只是 Apple 的人放出来秀肌肉（技术实力）的。『别看 V8 那么多人，还不是我们 Apple 才搞出来这个大新闻？』

但我个人不是很看好这个。

第一是在实现上的复杂性。Apple 说能搞定，但说起来容易做起来难。所谓『搞定』很重要一点是不造成 performance regression。这是为什么这篇 blog 如此之长 —— 很长篇幅是用来谈实现细节的，意思是我们能做到，你们（v8、chakra、monkey）不好意思说不行吧！然而即使 Apple 自信满满，其他引擎的人未必买账。这个事情过去也不是没发生过。PTC（尾调用优化），Chakra 的人说加 PTC 会影响我们的性能，Apple 的人都冲到 Chakra 的 repo 里亲自 review，就差手把手教写代码了，但最终还是没有卵用，说不实现就不实现。再比如 private field 之所以不能采用一般的 private 关键字写法，很大一个原因是对属性访问加可见性检查对性能会有严重影响。而这文章里也提到了，要上 Thread，如果给所有属性访问 naive 的全加 lock，性能马上下降 7、8 倍，甚至在 fastpath 下降 20 倍以上。固然 Apple 的人然后又说了他们如何牛逼的做到几乎没有性能损失，但那些优化方式对其他引擎来说未必适用，适用也未必能实现，能实现也未必成本可接受……毕竟这东西太复杂，涉及到许多底层且牵一发动全身的东西，比如 GC。

第二是对 JS 编程模型的影响。加入 Thread 显然会破坏 run-to-completion 语义。注意这和 SharedArrayBuffer 的区别。SharedArrayBuffer 虽然也不遵循 rtc，但范围仅限于 SharedArrayBuffer 对象，而且绝大部分 JSer 是用不到 SharedArrayBuffer 的，甚至都很少用 workers。扩展到所有 object 显然是另一回事情，对 JS 的编程模型影响巨大。这文章里说通过保障一些底层操作是原子的来确保遵循 JS 对象模型的 invariants。但我很怀疑是否能确保所有当前 spec 里规定的 invariants。如果仔细看过 spec 或看过 262 的一些 testcases，就会发现很多 invariants 可不是单个的原子操作可以确保的。无论如何，就算真要上 Thread，我个人比较 prefer 类似 SharedArrayBuffer 的方式，比如弄个 SharedObject，或者用 Thread.share(o) 来开启（跟此文中用 Thread.restrict(o) 来限制反一下）。

第三是语义上的复杂性。比如，根据当前 Apple 的提案，o.f 在简单 own prop 时是原子的，但是如果是原型上的 prop ，或者是 getter 就不是原子的了。当然，其实这也不是很重要，毕竟既然决定要上 Thread，必定要接触这些麻烦事。

最后，也是最重要的，是新特性的必要性。在已经有 SharedArrayBuffer 的前提下，我看不出加入 Thread 的必要性。有什么事情是 Thread 能而现有的 SharedArrayBuffer + Worker 不能（以同样性能达成）的吗？恐怕没有，最多就是写起来麻烦。实际上，worker 和 thread 本质上是相同的，区别只是 worker 默认不共享（想要共享你得自己构造 SharedArrayBuffer 传进去），thread 默认共享。Thread 对程序员的好处主要是模型比较成熟，可以照搬其他语言的经验，甚至直接移植库。但我个人认为，反正是 low-level，反正都要小心翼翼处理，能搞得定 thread 的程序员没理由搞不定 worker + SharedArrayBuffer，因此这优点很不明显。何况还有直接从 C++/Rust 之类编译到 asm.js / WebAssembly 的选择，既然是编译，管他最后用的是 wasm 还是 SharedArrayBuffer + worker 还是 Thread 呢？即使真的要改进 JS 中的 concurrent 编程体验，我宁可选择优先改善现有的机制，比如增加基于 (Shared)ArrayBuffer 的 UTF8StringView 和 struct，增加 Immutable 数据类型（从而可以安全的在多个 workers 中共享）……这些特性在实现上对引擎实现和编程模型的影响比 Thread 应该要小很多。而且即使将来还是要上 Thread，也仍然是有用的特性。也就是说我认为这些特性可以有更高的优先级。

总之，任何一份新特性的提案，首要的不是技术上的可行性，而是先要列出令人信服的 use cases 及现有特性为何不能解决这些 use cases 或有何不足。而这是这篇 blog 所欠奉的。

以上。

我还以为Thread是邪路是早已经达成了的共识了来的……