Specifying lockdown behavior
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- javascript, wasm
调研方向
Start with the component invariants section of design/mvp/Explainer.md and CanonicalABI.md, then review JS-API issue #686 and the removal in #705. Determine where lockdown semantics and failures during ToComponentValue and lowering should be specified; done means the location and behavior are agreed and the relevant specification is updated.
由索引模型根据 Issue 内容生成。
描述
Component invariants state:
Components define a "lockdown" state that prevents continued execution after a trap. This both prevents continued execution with corrupt state and also allows more-aggressive compiler optimizations (e.g., store reordering). This was considered early in Core WebAssembly standardization but rejected due to the lack of clear trapping boundary. With components, each component instance is given a mutable "lockdown" state that is set upon trap and implicitly checked at every execution step by component functions. Thus, after a trap, it's no longer possible to observe the internal state of a component instance.
I don't see anything in CanonicalABI.md about this, does this still need to be specified? There was a may_enter flag that was removed in #705.
I'm asking because the JS-API (#686) needs to care about lockdown semantics, and I wasn't sure if it should define it in the JS-API or in CanonicalABI.md.
For the JS-API, it'd be great to fuse the destructuring of JS values (ToComponentValue) with the lowering of the component value into linear memory. However, destructuring a JS value can fail (type mismatches) and also lowering the component value can fail (OOBs). So ideally we could have both kinds of failures lead to a lockdown of the component such that it's not observable what happened to the internal wasm state.
If this is just missing, I can add it to CanonicalABI.md, I think that's the right place for it.
- 主要语言
- WebAssembly
- 星标
- 1.4k
- 派生
- 132
- 平均合并
- 2 天 20 小时
- 30 天内合并 PR
- 13
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
WebAssembly/component-model 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
WebAssembly/component-model#609 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/component-model#731 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/component-model#724 · 10 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
WebAssembly/component-model#695 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 45/100
WebAssembly/component-model#694 · 1 条评论 ·
维护者通常 1 天内回复
查看 WebAssembly/component-model 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
run-llama/llama_index#23278 ·
维护者通常 2 天内回复
-
from-review-extraction priority: low python severity:nit
难度 2/5 1-3 小时 新手友好度 90/100
LearningCircuit/local-deep-research#6944 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
iMicknl/python-overkiz-api#2263 ·
维护者通常 7 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
meshery/meshery#22119 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
sgl-project/sglang#41482 ·
维护者通常 1 天内回复