Lock objects (GC feature + WebIDL tie-ins)
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 20/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- wasm
- 领域
- compilers
调研方向
从 issue #136 中的理由开始，包括其中描述的 WebAssembly GC 和 WebIDL 关联。在认为这项工作已准备好进行编码之前，先为 lock 对象确定具体的规范和实现范围；该 issue 目前记录的是设计讨论，而不是已定义的变更。
由索引模型根据 Issue 内容生成。
描述
(This is a post-all-the-MVPs feature; I'm recording it because the issue came up again in a conversation.)
When we added shared memory to JS it was motivated in large part by compiling C/C++ to asm.js, a focus that was at least in part inherited from NaCl/PNaCl; let's call this the "asm.js" use case for short. In this world there is only flat memory; asm.js has no host object support at all.
Thus when it came time to spec the atomic operations we were in a bind about locks: On the one hand we could add a lock data type and lock and unlock as primitive operations in both the code and the memory model. This would be nice for users and especially the JS side of the programs (well-tested lock primitives with good performance, and lock objects that could be postMessage'd to other threads) and perhaps for JIT compilers (in principle it's easier to move operations into critical sections than to move them across lower-level atomic operations). On the other hand, it created a specification and implementation headache since lock "objects" would have to be specified external to asm.js with some sort of "integer handle" model, leading to a GC problem at least, or locks would have to be allocated in flat shared memory and would not have any kind of encapsulation - there are many problems. Furthermore, the semantics of lock objects might not map cleanly onto the semantics of whatever source language or thread library we were compiling from, so a flexible mechanism was required anyway. And thus we got atomics and futexes.
Wasm changes the calculus somewhat here with its typed references. We can now have a primitive lock object type (ref Lock) and lock and unlock operations in the instruction set and as JS methods (and other data types and operations besides). Code compiled from a language that has awareness of wasm gc objects and not from a legacy language such as C++ could perhaps make use of such lock objects. Our JIT compilers could generate good code and exploit optimization opportunities.
Wasm also changes the calculus with the WebIDL bindings, in that we could get much of the benefit of lock objects just with type imports and inlined methods on known built-in types. It leaves non-WebIDL embeddings high and dry, but it's good for the web (to the extent shared memory and locks are good for the web) and allows us to experiment more.
No code would be precluded from using flat memory for their own locks, of course, so this would all be strictly additive no matter which way we go.
- 主要语言
- WebAssembly
- 星标
- 769
- 派生
- 54
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
WebAssembly/threads 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
WebAssembly/threads#254 ·
-
难度 5/5 一周以上 新手友好度 30/100
WebAssembly/threads#253 · 6 条评论 ·
-
难度 4/5 3-5 天 新手友好度 35/100
WebAssembly/threads#245 · 1 个 reaction ·
-
难度 4/5 3-5 天 新手友好度 35/100
WebAssembly/threads#240 ·
-
Branch renaming未关闭
难度 1/5 1 小时以内 新手友好度 20/100
WebAssembly/threads#237 ·
查看 WebAssembly/threads 的全部 Issue
相似的 Issue
-
vxc prints a debug line '[flat-codegen] emitted module via the flat path' on every compile可能已有人在做 @YodHeVauHe 今天认领。 未关闭devex good first issue
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
SciML/ModelingToolkit.jl#5255 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
NVIDIA/cuda-quantum#5539 ·
维护者通常 1 天内回复
-
triage
难度 2/5 1-3 小时 新手友好度 70/100
NVIDIA/cuda-python#3015 · 2 条评论 ·
维护者通常 1 天内回复