Naming convention for wait/notify instructions
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- wasm
- Área
- compilers
Línea de trabajo
Empieza leyendo el contexto de la propuesta de threads y la nomenclatura existente de las instrucciones wait/notify. Compara las alternativas de nomenclatura enumeradas en este issue con las convenciones para otras instrucciones de memoria. Se considera hecho cuando la propuesta tiene un esquema de nomenclatura decidido y compatible con el futuro, en lugar de un conjunto de opciones sin resolver.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The threads proposal as is is limited to shared memories, but we probably want to generalise the language to other shared entities eventually, e.g., globals or tables. At that point, it might be conceivable that we may want to introduce not just atomic get/set for those, but also wait/notify instructions.
However, the current naming scheme for wait/notify instructions does not make explicit that they are operating on a memory. In the interest of forward compatibility, should we fix that? It might also be nice for improved consistency with other memory instructions.
Bikeshedding possibilities:
memory.atomic.notify,i32.memory.atomic.waitmemory.atomic.notify,memory.i32.atomic.waitmemory.atomic.notify,memory.atomic.wait32
Admittedly, neither pair is particularly pretty. Thoughts?
- Lenguaje dominante
- WebAssembly
- Estrellas
- 769
- Forks
- 54
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de WebAssembly/threads
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
WebAssembly/threads#254 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
WebAssembly/threads#253 · 6 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
WebAssembly/threads#245 · 1 reacción ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
WebAssembly/threads#240 ·
-
Branch renamingAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 20/100
WebAssembly/threads#237 ·
Todos los issues de WebAssembly/threads
Issues similares
-
Discover carries headerEdges that nothing reads since #1914 moved E0507/E0517 to the compiler graphAbiertotech-debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
VX_PRINT_DROPS prints each drop point twice on the default code generator, the second time at line 0Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Bisect issue229646Abiertobisect
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
dtcxzyw/llvm-bisect-service#418 · 1 comentario ·
-
area:prove bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Chelis-Lang/chelis#3317 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
leanprover/lean4#15529 · 1 comentario ·
Los mantenedores suelen responder en 1 día