Design: pThreads 任何 ETA 吗？

在接下来的几个季度中的某个时间可能与任何人所说的一样精确。 但请保留问题跟踪器以提交问题。

该项目没有邮件列表或其他论坛，因此问题跟踪器是人们可以就设计过程提出问题的唯一地方。 有一个人们可以提问的地方很有价值，因此我鼓励人们继续使用问题跟踪器来提问。

@sunfishcode ，很公平，但我建议我们创建这样一个列表。 我不认为问题跟踪器是一个合适的替代品。

有w3 公开列表。 不过，它并没有遇到非常繁忙的交通。 我相信还有一个IRC？ 我认为它在某个时候在网站上，但如果它们都直接链接到网站的社区部分会很好。 我会打开一个问题，但我不确定你们都喜欢哪些途径~暴露~与公众联系

这里的说明：

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

我们一直在指导人们使用 github。 不是每个人都喜欢它，但拥有一个地方比拥有许多地方要好。

嗨@rossberg-chromium，感谢您的及时答复。

但请保留问题跟踪器以提交问题。

正如@jfbastien所指出的，我在这里问是因为它似乎是以标准方式进行操作的最佳场所。
此外，线程支持是webAssembly成败的设计特性。
不仅仅是徽标上下文和“为什么它没有在 java 中实现”，我认为这是一个问题。

如果我错了，请告诉我在哪里遵循共享内存/线程实现。
这应该是一个开放的过程，所以我想发表意见。

--R

@RobertoMalatesta我们同意线程非常重要，但让它们正确比将它们塞进 WebAssembly 的最低限度可行产品更重要。 我们的理由很简单：asm.js 在没有这个特性的情况下取得了成功。

线程对于一些重要的应用程序来说绝对是一个决定成败的特性，但它并不适用于所有应用程序。 GC、零成本异常处理、保证尾调用等也是如此。

选择做 MVP 意味着我们不会在第一次发布时让每个人都开心。 这也意味着有些人在我们设计、规范和实现所有东西之前就开始使用 WebAssembly。

话虽如此，我们希望或多或少地在 WebAssembly 中采用JavaScript SharedArrayBuffer方法。 我们中的许多人从一开始就参与了该规范。 它将添加类似于 C++ 的低级功能，以及类似 futex 的 API。 与顺序一致性相比，它有更多的内存排序空间来增长。 正在为它创建一个正式的记忆模型。

SAB 在 TC39 中处于“第 4 阶段”，这意味着它已经完成，准备好发货，可以使用了。 我希望将它应用到 WebAssembly 中不会太困难。

@jfbastien感谢您提供的有见地的信息。

话虽如此，我们希望或多或少地将 JavaScript SharedArrayBuffer 方法应用到 WebAssembly 中。(...)
SAB 在 TC39 中处于“第 4 阶段”，这意味着它已经完成，准备好发货，可以使用了。 我希望将它应用到 WebAssembly 中不会太困难。

伟大的。 我渴望用大量的 C++ 代码来解决它，而这些代码只是渴望线程化。
我经常在我的 TS/JS 应用程序中使用 WebWorkers，让我说我不是它们的粉丝，但它们可以作为第一个开始。

线程非常重要，但让它们正确比将它们塞进 WebAssembly 的最低限度可行产品更重要。 我们的理由很简单：asm.js 在没有这个特性的情况下取得了成功。

完全理解 MVP 快速退出的需求（我认为这就是放弃 AST 转向基于堆栈的原因）以及计划进一步步骤所需的关注。

线程对于一些重要的应用程序来说绝对是一个决定成败的特性，但它并不适用于所有应用程序。 GC、零成本异常处理、保证尾调用等也是如此。

作为 emscripten 的长期用户，我希望 WebAssembly 与 Javascript 应用程序堆栈限制更加分离：

Wasm 应该只 1) 以最高性能为目标，2) 为套接字、内存/线程、GDI、fs 提供一些 Posix/Unix/BSD 标准。 这样，它将是一个类似于操作系统的薄层，既可以作为统一的目标平台嵌入到移动设备中，也可以嵌入到服务器中以竞争可部署云的应用程序。

这是长期未来的方向还是我完全错过了这条船？

再次感谢您的工作，

罗伯托

Wasm 绝对与一些堆栈限制解耦，因为我们如何将本地变量与诸如 LLVM 之类的编译器需要放入用户可访问的内存中的内容分开。

使用线程，特别是如果它们不是基于 Worker 的，您将在那里获得更多的权力。

话虽如此，最好能获得更多关于你的精确想法的细节。 用例是什么，如何在 C++ 中解决它，以及 wasm 实现如何做到这一点？

我不希望你想出所有的答案！ 就是现在想到的。 Fwiw C++ 对堆栈限制提出了一些建议。 查看 SG14 子组。

对不起，细节太少了，我在👶🌯。 以后会更好的回答！

抱歉，细节太少了，我在吃:baby:: burrito:。 以后会更好的回答！

你在婴儿卷饼下吗？ 哈哈

@qwertie

你在婴儿卷饼下吗？ 哈哈

从字面上看，一个包裹着的婴儿。

嗨@jfbastien ，

获得有关您的精确想法的更多详细信息会很好。 用例是什么，如何在 C++ 中解决它，以及 wasm 实现如何做到这一点？

一般来说，我的用例是构建模拟软件，在计算部分，限制只有机器，这要归功于 C++、C/OpenCL 和 GPU 技术。

在前端，堆栈 HTML5+CSS+Javascript+Typescript 已被证明是开发中大型复杂应用程序的有效、经过验证、可移植的方式。

_ 如今，JS Web Stack（添加了诸如Typescript之类的结构化语言）非常好，以至于我觉得没有必要在大多数应用程序中使用 emscripten 或尝试使用 wasm。_

我几乎完全同意高级目标和Webassembly 用例，甚至更同意Non-Web Embeddings Document 。

_ WebAssembly将是一项相关技术（至少对我而言），如果它允许更快（对于本机 C 应用程序加上，比如 5% 开销）使用更多内存和更自由，完全实现端口/套接字并允许像任何普通操作系统一样运行线程。_

Wasm 机器的大小应该非常灵活，速度快且具有预测性，因此请不要坚持使用 GC：GC 是 IT 的庞氏骗局：您欠债并且不关心分配，直到为时已晚并且您失去周期. 此外，如果我们有一个性能超强的 wasm 核心机器，那么可以在它之上构建一个 GC。

为了圆滑，我会逐步将它与 Javascript 分离。 如果我有任何语言的本机编译器，那么我不需要脚本，无论如何我可以通过在 C 源代码中编译来嵌入 Duktape/Lua/whatever。

在 Mozilla 网站的某个地方，我看到了有关实现 wasm 原生 DOM 操作的文档：我认为它不会很有用，因为 DOM 操作本质上是顺序的，并且它是 HTML5/CSS/JS 堆栈中最耗时的方面之一：如果我编写超高速多线程 wasm 只是为了让我的 DOM 更改在队列中序列化等待，然后所有性能都消失了，与使用 C/C++ 相比，编译一些 Typescript 更好。 在这种情况下，我倾向于直接 OpenGL 访问（首先使用一些 WebGL 实现，然后使用 OpenGL 本机）。 访问显卡将证明对提供 GPU/CUDA 功能很有用，而且开销很小或没有开销。
（刚刚去检查这个并得到问题＃273解决这个问题）

拥有一个由每个供应商和独立者共享的小型 wasm 机器也可以解决移动开发的噩梦，你至少有 4 个工具链用于不同的操作系统、版本和架构。
图形和输入设施可能会有所不同，但我们可以开发成一个 wasm，然后查询设施 API，甚至在不同的应用商店上部署相同的应用程序。
从长远来看：服务器应用程序也是如此，就设施（数据库连接协议和池、黄页系统、消息传递协议和系统等）达成某种共识，并将它们打包成一些标准规范，就像 JEE 平台所做的那样。 （在过去的 20 年里，很多概念性工作已经完成）。

我不希望你想出所有的答案！ 就是现在想到的。 Fwiw C++ 对堆栈限制提出了一些建议。 查看 SG14 子组。

我当然会。

感谢您的耐心和时间。

抢

作为一个小补充，当实现线程时，如果堆栈大小可以任意大，或者作为替代，如果它可以设置为至少 64MB，那就太好了。 这是因为我的用例是一个使用 2 个线程的应用程序，非主线程需要一个相当大的堆栈。

@jjpe这将是对针对 wasm 的特定工具链（例如 emscripten）的请求，而不是针对此 repo，因为这是工具链选择实现或 ABI 的问题，而不是关于 wasm 平台本身的问题。 （例如，您可以在 https://github.com/kripken/emscripten/ 上打开一个问题）

我在之前的信息中提出的一些内容似乎包含在最新的 WASI 提案中。
看：
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

十指交叉。

--R

FWIW 目前的状态是 Chrome 在版本 74 中提供了 wasm 线程支持，Firefox 有一个尚未发布的实现，并且 Emscripten 有 pthreads 支持 (https://emscripten.org/docs/porting/pthreads.html) wasm 现在可用。

（WASI 也是一个系统调用 API，它主要与给定的 wasm 嵌入或工具链是否支持线程/原子无关）。

是否有关于如何使用 Chrome 和 Firefox 线程 API 的文档？

这是一种事物的组合。 浏览器的 wasm 引擎实现了对 wasm 规范 (https://github.com/WebAssembly/threads/tree/master/proposals/threads) 的线程/原子扩展，它允许实例化共享的 wasm 内存。 在 Web 上，您可以创建一个 Web Worker，并通过 postMessage 将内存（以及任何相关的 wasm 模块）发送给该 Worker。 然后，您使用工作线程（以及主线程或另一个工作线程）上的共享内存来实例化模块，并且实例共享它们的内存。 规范提案概述（https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md）有一个小例子，但我不知道其他人。

嗨@dschuff ，感谢上面的回答。
在我之前的消息中，我指的是之前的消息，不仅涉及 pthreads，而且还涉及将 wasm 理想地演变成更类似于内核的东西，我们中的一些人自 2010 年以来一直在使用 emscripten 并将其视为真正的突破性技术。
请参阅： https ://github.com/WebAssembly/design/issues/992#issuecomment -285055578。

在 emscripten 出现九年后，也就是在 wasm 发布将近五年之后，在将 wasm 转变为可行的服务器技术方面进展甚微。

可悲的是，因为我们需要一个可移植应用程序的标准，而最好的方法是实现一个带有 POSIX 线程和伯克利套接字的微型内核（类似 BSD/Linux）+ 一个自包含的安全虚拟文件系统（与用户组就足够了）。 我坚信 H.Spencer 的老话：“不懂 UNIX 的人注定要重新发明它”。

我仍然想保持信念，所以 WASI 是朝着正确方向迈出的一步。

--R

PS：2010 emscripten 仍然很出色，因为它可以在不朽的浏览器中运行，这是大多数企业中使用的不可描述的不可杀死的浏览器，它将看到 Firefox 和 Safari 的主体漂浮（至少它们的引擎）。