Revisiting the edge-case semantics of wake
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
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- wasm
- Área
- compilers
Línea de trabajo
Empieza leyendo la semántica actual de wake y la propuesta de este issue; después revisa WebAssembly/threads#72 y la referencia enlazada de ECMAScript Atomics.wake. Comprueba las notas históricas de las encuestas del CG para consultar decisiones anteriores. Se considerará completado cuando haya una resolución semántica acordada y las actualizaciones correspondientes de la especificación, pero este issue no menciona archivos de implementación ni pruebas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Currently
The current semantics of wake is as follows:
Wake consumes two operands, an i32 address, and an i32 wake count.
The wake count operand is interpreted as a signed value, and the following behaviour occurs based on this value:
wake count value |
Behavior |
|---|---|
wake count < 0 |
Wake all waiters |
wake count == 0 |
Wake no waiters |
wake count > 0 |
Wake min(wake count, num waiters) waiters |
Let num woken be the number of threads woken by this operation.
The result of the wake operation is num woken if num woken can be represented as an i32, and trap otherwise.
Proposal
I propose instead to interpret the wake count operand as an unsigned value, with the following behaviour
wake count value |
Behavior |
|---|---|
| --- | Wake min(wake count, num waiters) waiters |
The result of the wake operation is num woken, which is guaranteed to be representable as an i32.
Reasoning
From discussions in TPAC and elsewhere (https://github.com/WebAssembly/threads/issues/72), there were concerns about the behaviour of the operation when the number of waiting threads is greater than UINT32_MAX. There was also some concern about conformity to JS, but this seems to be a red herring as JS takes a float to represent its wake count, waking all threads if passed ∞, and otherwise clamping the value to max(ToInteger wake count, 0) with no concern for the UINT32_MAX edge-case (link).
Consider that if there really are more than UINT32_MAX waiting threads, neither implementation can wake all of them in one operation (must use a loop), the former because it would trigger a trap, and the latter because the number to wake is not representable.
Polls in previous CGs appear very inconclusive, and focussed on i32 vs i64 representation. I don't have a strong opinion on the representation issue, but I think adding a trap case to the semantics isn't the right approach, and interpreting the num waker argument as signed is slightly rogue.
This all seems to be perfectly theoretical anyway. At least on linux, superficial googling suggests that there are several internal limits that restrict maximum thread numbers to the order of millions, even on 64-bit systems, with a very hard limit of 2^29 due to their implementation of PIDs. Several linux syscalls assume that the number of waiters can be represented using i32. There's also a blogpost on experimentally pushing the envelope in Windows which doesn't get anywhere near 2^32.
This hopefully means that the semantic change won't break anything, as a negative wake count argument will now be interpreted as a ginormous positive one (at least 2^31).
- 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
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
cc65/cc65#3000 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
I-prioritize needs-triage regression-from-stable-to-beta T-lang
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rust-lang/rust#163830 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Swift route tables omit digit constraints from generated main and testsPosiblemente ocupada @dchuk la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
rubys/roundhouse#444 ·
Los mantenedores suelen responder en 1 día
-
IntrinsicLowering::LowerCTPOP runs into assertion with LLVM 23Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertocrash llvm:codegen
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
llvm/llvm-project#229064 ·
Los mantenedores suelen responder en 1 día
-
area:lowering kind:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día