Design: Atómica y memoria compartida
De acuerdo con la Agenda para la 53ª reunión de Ecma TC39 La memoria compartida y los átomos van a la etapa 3. Eso significa que su API se congelará. Por lo tanto, el martes 26 de julio podría convertirse en una fecha límite para realizar cambios en las especificaciones en caso de que la visión de WebAssembly Community Group difiera de la visión de TC39.
Propuesta de ES: https://github.com/tc39/ecmascript_sharedmem
chicoxyzzy
Todos 5 comentarios
Mi pregunta es: ¿Todos están de acuerdo con copiar las limitaciones del hilo principal en esa especificación a WASM?
taisel
en 20 jul. 2016
@chicoxyzzy , hubo una larga discusión sobre sab + wasm aquí: https://github.com/tc39/ecmascript_sharedmem/issues/59
@taisel , ahora estoy siendo pedante, pero aún así: las "limitaciones del hilo principal" no son técnicamente parte de esa especificación. La especificación permite que algunos subprocesos se nieguen a bloquearse (según los criterios elegidos por la implementación), y claramente esa facilidad está motivada por los subprocesos principales de los navegadores, pero no es necesario que el uso de la memoria compartida JS + en una configuración diferente al navegador tener esa limitación. No veo cómo se encuentra el wasm en una situación diferente. Además, pude ver algunos tipos de trabajadores, como SharedWorkers, usando memoria compartida, pero no se les permite bloquear.
De hecho, que TC39 requiera que los navegadores permitan el bloqueo en el hilo principal no conduciría a nada fructífero, solo a conflictos, y probablemente pondría en peligro la implementación de toda la propuesta de memoria compartida. Lo que tenemos ahora es una extensión bastante conservadora del lenguaje y los navegadores que encaja en el ecosistema web existente. Sabemos que el proxy puede resolver algunos problemas; sabemos que el bloqueo "asimétrico" (los trabajadores bloquean pero el hilo principal no) puede resolver otros problemas; necesitamos adquirir algo de experiencia con esto para descubrir dónde están los verdaderos puntos débiles, y luego podemos ver cómo abordarlos. Tratar de hacer cumplir el bloqueo en el hilo principal es la opción nuclear, en esta etapa.
lars-t-hansen
en 20 jul. 2016
@ lars-t-hansen Sí, y reiteré esa limitación suave para alentar la discusión.
Todavía hay un grupo de personas que pensé que querrían que la migración fuera lo más indolora posible, y no conozco muchas concesiones que el comité WASM quiera hacerles.
taisel
en 20 jul. 2016
Para agregar a lo anterior, la sección WebAssembly de Discussion.md tiene un buen resumen de la discusión de sab + wasm.
sunfishcode
en 26 jul. 2016
La propuesta de roscado inicial está diseñada para coincidir con el comportamiento de los trabajadores de SAB +, por lo que es poco probable que se mueva el barco aquí. Hemos hablado de tener subprocesos de "wasm puro", que no tienen un contexto de JavaScript, pero decidimos abordarlo mejor después de alcanzar la paridad de funciones con JavaScript + SAB.
Además, la especificación html ahora se ha integrado con el bloqueo WRT de la Atomics.wait ).
binji
en 9 may. 2017
Temas relacionados
frehberg
·
6Comentarios
jfbastien
·
6Comentarios
beriberikix
·
7Comentarios
nikhedonia
·
7Comentarios
aaabbbcccddd00001111
·
3Comentarios
Comentario más útil
@chicoxyzzy , hubo una larga discusión sobre sab + wasm aquí: https://github.com/tc39/ecmascript_sharedmem/issues/59
@taisel , ahora estoy siendo pedante, pero aún así: las "limitaciones del hilo principal" no son técnicamente parte de esa especificación. La especificación permite que algunos subprocesos se nieguen a bloquearse (según los criterios elegidos por la implementación), y claramente esa facilidad está motivada por los subprocesos principales de los navegadores, pero no es necesario que el uso de la memoria compartida JS + en una configuración diferente al navegador tener esa limitación. No veo cómo se encuentra el wasm en una situación diferente. Además, pude ver algunos tipos de trabajadores, como SharedWorkers, usando memoria compartida, pero no se les permite bloquear.
De hecho, que TC39 requiera que los navegadores permitan el bloqueo en el hilo principal no conduciría a nada fructífero, solo a conflictos, y probablemente pondría en peligro la implementación de toda la propuesta de memoria compartida. Lo que tenemos ahora es una extensión bastante conservadora del lenguaje y los navegadores que encaja en el ecosistema web existente. Sabemos que el proxy puede resolver algunos problemas; sabemos que el bloqueo "asimétrico" (los trabajadores bloquean pero el hilo principal no) puede resolver otros problemas; necesitamos adquirir algo de experiencia con esto para descubrir dónde están los verdaderos puntos débiles, y luego podemos ver cómo abordarlos. Tratar de hacer cumplir el bloqueo en el hilo principal es la opción nuclear, en esta etapa.