Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Specifying lockdown behavior

Aperta
#727 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
javascript, wasm
Ambito
api, compilers

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
WebAssembly
Stelle
1.4k
Fork
130
Merge medio
2g 23h
PR unite (30g)
14

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WebAssembly/component-model

Tutte le issue di WebAssembly/component-model

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.