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

Allowing instantiation of modules that import linear memory as shared, with unshared memory

Aperta
#82 8 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
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
wasm
Ambito
compilers

Direzione di ricerca

Non sono indicati file, test o punti di ingresso. Inizia leggendo le regole di validazione e istanziazione delle importazioni di memoria condivisa di WebAssembly descritte nell’issue, quindi individua il testo della specifica e i test rilevanti della proposal. Il lavoro è completato quando si è raggiunto un accordo sul fatto che le memorie non condivise possano soddisfare le importazioni di memoria condivisa e si sono aggiornati di conseguenza la specifica e la copertura di conformità.

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

Descrizione

First a caveat that this isn't really about shared-everything (i.e. GC) but about linear memory; but since the threads proposal went to phase 4 this is the current catch-all place to discuss shared memory.

Currently if you compile a module that imports a shared memory, instantiation will fail if the memory you pass at instantiation time is non-shared. This seems like an unnecessary restriction, since even if the module has already been compiled with real atomics, those atomics should still work fine if executed in a single-threaded context. This is somewhat analogous to the fact that atomics are allowed on nonshared memories (i.e. this could be seen as the "dynamic" version of that existing "static" allowance), and also to the fact that we allow loosening of growth restrictions at instantiation time (e.g. instantiating with a memory with a larger maximum size compared to what the module was compiled for).

The use case here would be when an app doesn't know whether or not it would be executed in an origin-isolated web context that allows SharedArrayBuffer. So it could use the same module, and then instantiate it one way or the other. Because atomics are allowed on non-shared memories already, this can be worked around today by actually modifying the bytes of the module's import section before instantiation but that's obviously hacky and loses the benefits of streaming compilation. So it would be much better just to loosen the restriction in the spec here.
/cc @eyebrowsoffire

Lingua principale
WebAssembly
Stelle
97
Fork
6
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

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/shared-everything-threads

Tutte le issue di WebAssembly/shared-everything-threads

Issue simili

Altre issue su Compilers

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.