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

Introduce flag to prevent reallocation of shared memory

Aperta
#173 0 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
wasm

Direzione di ricerca

La issue non indica file del repository, test o punti di ingresso dell'implementazione; inizia esaminando la proposta WebAssembly threads e gli esempi di istanziazione di shared memory nel report. Stabilire se una cache di memoria o un flag associato al modulo rientrino nell'ambito, definirne il ciclo di vita e la semantica di incapsulamento e documentare i criteri di compatibilità e validazione prima dell'implementazione.

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

Descrizione

Instantiating a module more than once allocates new memory for each instance, what if, instead, there could be a flag that would cause all instances to refer to the same memory?
Instead of them being thread-local memories, they would be "global."

This allows Wasm to remain completely self-contained, encapsulated, and in control of its own memory.
Currently, shared memory is completely useless if not importing host shared memory, but every step in between the module getting its memory, and the host passing it to the module, leaves room for mutation, and unexpected change at runtime, as the host has control over the array buffer too.

Nothing more would need to be changed, it would just change the lifetime of the memory.

This could be implemented as a simple cache associated with the module.

Current loading (JS):

// main.mjs:
const memory = new WebAssembly.Memory({ ..., shared: true });

const {
    instance,
    module
} = await WebAssembly.instantiateStreaming(..., ...memory...);

const thread = new Worker("./worker.mjs", ...);

worker.postMessage({ memory, module });

// worker.mjs:
... // await .postMessage({ memory, module })
const instance = await WebAssembly.instantiate(module, ...memory...);

With cached memory:

// main.mjs:
const {
    instance,
    module
} = await WebAssembly.instantiateStreaming(...);

const thread = new Worker("./worker.mjs", ...);

worker.postMessage(module);

// worker.mjs:
... // await .postMessage(memory)
const instance = await WebAssembly.instantiate(module);

In the former example, the WebAssembly module's memory may be corrupted later at the will of the host, breaking encapsulation, but the way that multi-threaded Wasm loading works, it leaves no alternative.

Would this break any of the core motivations/ideas/philosophies behind WebAssembly?

Lingua principale
WebAssembly
Stelle
767
Fork
54
Metriche di merge delle PR
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/threads

Tutte le issue di WebAssembly/threads

Issue simili

Altre issue su Operating Systems

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.