Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Introduce flag to prevent reallocation of shared memory

Abierto
  • ¿Algo no está bien?
#173 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
wasm
Área
operating-systems

Línea de trabajo

El issue no menciona archivos del repositorio, pruebas ni puntos de entrada de la implementación; empieza revisando la propuesta de WebAssembly threads y los ejemplos de instanciación de shared memory del informe. Determina si una caché de memoria o un flag asociado al módulo están dentro del alcance, define su ciclo de vida y su semántica de encapsulación, y documenta los criterios de compatibilidad y validación antes de la implementación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
WebAssembly
Estrellas
769
Forks
54
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/threads

Todos los issues de WebAssembly/threads

Issues similares

Más issues de Operating Systems

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.