Web worker是否是浏览器创建的普通本机线程，可以与其他具有消息队列的浏览器线程一起运行和通信？或者在创建时它是否包含其他内容？
我正在查看emscripten中的experimental support of pthread，C ++中的多个线程将在编译后转换为Web worker。但它是否具有与本机代码相同的性能水平？所有细粒度多线程都是C ++的一个关键特性。
答案 0 :(得分：3)
目前，WebWorkers非常重要，因为VM复制了一堆内部状态（有时甚至为工作者重新编写JIT代码）。该状态 大于本机线程的初始堆栈空间和关联状态的少量MiB。
其中一些可以通过实现来解决，我希望如果SharedArrayBuffer或WebAssembly + threads变得流行，那么浏览器引擎会想要优化。
话虽这么说，你的问题的结尾暗示了对什么线程开销的误解，以及SharedArrayBuffer（Emscripten依赖于支持pthreads）的提议如何工作。 WebWorkers目前很重，但他们可以通过SAB以与C ++等本机代码完全相同的方式进行通信：通过访问完全相同的内存，在同一个虚拟地址。 SAB为JavaScript添加了一种新的ArrayBuffer，当你postMessage给另一个工作者时，它不会被扼杀。然后，当您使用std::atomic时，多个工作人员可以使用与C ++代码完全相同的方式查看其他工作人员对缓冲区的更新。
同时，工作人员不能按照定义阻止主线程，因此有更多的本地＆＃34;感觉。有些网络API并非适用于所有工作人员，但这种情况正在发生变化。如果你这样做就变得相关了写一个游戏，并在不同的线程中有网络/音频/渲染/ AI /输入。网络正在慢慢找到自己做这些事情的方式。
细节有点棘手
SAB目前仅支持非原子访问，并且顺序一致的访问（即此时唯一可用的Atomic访问与C ++的std::memory_order_seq_cst相同。进行非原子访问应该与C ++的非原子性一样高效（这里有大量的编译器注意事项，我不会进入），使用Atomic应该具有高效性能。作为C ++的std::atomic默认值（std::memory_order_seq_cst）。 C ++有5个其他内存顺序（relaxed，consume，acquire，release，acq_rel），SAB目前不支持这些内存顺序。这些其他内存顺序允许本机代码在某些情况下更快，但更难以正确和可移植地使用。它们可能会添加到SAB的未来更新中，例如通过this issue。
SAB还支持Futex本机程序所依赖的mutex，以实现高效{{1}}。
与C ++ I've detailed some of them比较时，甚至有更复杂的细节，但还有更多。