Design: Propuesta: API JS Async / Await

Esta propuesta se desarrolló en colaboración con @fmccabe , @thibaudmichaud , @lukewagner y @kripken , junto con los comentarios del Subgrupo Stacks (con una votación informal aprobando el avance a la Fase 0 hoy). Tenga en cuenta que, debido a limitaciones de tiempo, el plan es tener una presentación muy rápida (es decir, 5 minutos) y votar para avanzar a la Fase 1 el 3 de agosto. Para facilitar eso, recomendamos encarecidamente a las personas que planteen sus inquietudes aquí con anticipación para que podamos determinar si hay alguna inquietud importante que ameritaría retrasar la presentación + voto para una fecha posterior con más tiempo.

El propósito de esta propuesta es proporcionar una interoperabilidad relativamente eficiente y relativamente ergonómica entre las promesas de JavaScript y WebAssembly, pero trabajando bajo la restricción de que los únicos cambios son en la API de JS y no en el núcleo de wasm.
La expectativa es que la propuesta de Stack-Switching eventualmente extenderá WebAssembly central con la funcionalidad para implementar las operaciones que proporcionamos en esta propuesta directamente dentro de WebAssembly, junto con muchas otras valiosas operaciones de stack-switching, pero que este caso de uso particular para el cambio de pila tenía suficiente urgencia para merecer una ruta más rápida a través de solo la API de JS.
Para obtener más información, consulte las notas y diapositivas de la reunión del subgrupo de pila del 28 de junio de 2021 , que detalla los escenarios de uso y los factores que tomamos en consideración y resume la justificación de cómo llegamos al siguiente diseño.

ACTUALIZACIÓN: Después de los comentarios que el Subgrupo de Pilas había recibido de TC39, esta propuesta solo permite suspender las pilas de WebAssembly; no realiza cambios en el lenguaje JavaScript y, en particular, no habilita indirectamente la compatibilidad con asycn / await en JavaScript.

Esto depende (vagamente) de la propuesta js-types , que introduce WebAssembly.Function como una subclase de Function .

Interfaz

La propuesta es agregar la siguiente interfaz, constructor y métodos a la API de JS, con más detalles sobre su semántica a continuación.

interface Suspender {
   constructor();
   Function suspendOnReturnedPromise(Function func); // import wrapper
   // overloaded: WebAssembly.Function suspendOnReturnedPromise(WebAssembly.Function func);
   WebAssembly.Function returnPromiseOnSuspend(WebAssembly.Function func); // export wrapper
}

Ejemplo

El siguiente es un ejemplo de cómo esperamos que uno use esta API.
En nuestros escenarios de uso, nos pareció útil considerar que los módulos de WebAssembly tienen conceptualmente importaciones y exportaciones "sincrónicas" y "asincrónicas".
La API JS actual solo admite importaciones y exportaciones "síncronas".
Los métodos de la interfaz Suspender se utilizan para envolver las importaciones y exportaciones relevantes con el fin de hacer "asincrónicas", con el objeto Suspender en sí mismo conectando explícitamente estas importaciones y exportaciones para facilitar tanto la implementación como la componibilidad.

Montaje web ( demo.wasm ):

(module
    (import "js" "init_state" (func $init_state (result f64)))
    (import "js" "compute_delta" (func $compute_delta (result f64)))
    (global $state f64)
    (func $init (global.set $state (call $init_state)))
    (start $init)
    (func $get_state (export "get_state") (result f64) (global.get $state))
    (func $update_state (export "update_state") (result f64)
      (global.set (f64.add (global.get $state) (call $compute_delta)))
      (global.get $state)
    )
)

Texto ( data.txt ):

19827.987

JavaScript:

var suspender = new Suspender();
var init_state = () => 2.71;
var compute_delta = () => fetch('data.txt').then(res => res.text()).then(txt => parseFloat(txt));
var importObj = {js: {
    init_state: init_state,
    compute_delta: suspender.suspendOnReturnedPromise(compute_delta)
}};

fetch('demo.wasm').then(response =>
    response.arrayBuffer()
).then(buffer =>
    WebAssembly.instantiate(buffer, importObj)
).then(({module, instance}) => {
    var get_state = instance.exports.get_state;
    var update_state = suspender.returnPromiseOnSuspend(instance.exports.update_state);
    ...
});

En este ejemplo, tenemos un módulo WebAssembly que es una máquina de estado muy simplista: cada vez que actualiza el estado, simplemente llama a una importación para calcular un delta y agregarlo al estado.
Sin embargo, en el lado de JavaScript, la función que queremos usar para calcular el delta resulta que debe ejecutarse de forma asíncrona; es decir, devuelve una Promesa de un Número en lugar de un Número en sí.

Podemos cerrar esta brecha de sincronía utilizando la nueva API de JS.
En el ejemplo, una importación del módulo WebAssembly se ajusta con suspender.suspendOnReturnedPromise , y una exportación se ajusta con suspender.returnPromiseOnSuspend , ambos con el mismo suspender .
Ese suspender conecta a los dos juntos.
Hace que, si alguna vez la importación (sin empaquetar) devuelve una Promesa, la exportación (empaquetada) devuelve una Promesa, con todos los cálculos intermedios "suspendidos" hasta que se resuelva la Promesa de la importación.
El empaquetado de la exportación consiste esencialmente en agregar un marcador async , y el empaquetado de la importación esencialmente agrega un marcador await , pero a diferencia de JavaScript, no tenemos que enhebrar explícitamente async / await través de todas las funciones intermedias de WebAssembly!

Mientras tanto, la llamada realizada a init_state durante la inicialización necesariamente regresa sin suspender, y las llamadas a la exportación get_state también regresan siempre sin suspender, por lo que la propuesta aún admite las importaciones y exportaciones "síncronas" existentes. que utiliza el ecosistema WebAssembly en la actualidad.
Por supuesto, hay muchos detalles que se están repasando, como el hecho de que si una exportación síncrona llama a una importación asincrónica, el programa interceptará si la importación intenta suspender.
A continuación, se proporciona una especificación más detallada, así como una estrategia de implementación.

Especificación

Un Suspender encuentra en uno de los siguientes estados:

• Inactivo : no se está utilizando en este momento
• Activo [ caller ] - el control está dentro de Suspender , siendo caller la función que llamó al Suspender y está esperando un externref para ser devuelto
• Suspendido : actualmente esperando que se resuelva alguna promesa

El método suspender.returnPromiseOnSuspend(func) afirma que func es un WebAssembly.Function con un tipo de función de la forma [ti*] -> [to] y luego devuelve un WebAssembly.Function con el tipo de función [ti*] -> [externref] que hace lo siguiente cuando se llama con argumentos args :

1. Trampa si el estado de suspender no está Inactivo
2. Cambia el estado de suspender a Activo [ caller ] (donde caller es la persona que llama actualmente)
3. Permite que result sea ​​el resultado de llamar a func(args) (o cualquier trampa o excepción lanzada)
4. Afirma que el estado de suspender es Activo [ caller' ] por unos caller' (debería estar garantizado, aunque la persona que llama podría haber cambiado)
5. Cambia el estado de suspender a Inactivo
6. Devuelve (o vuelve a lanzar) result a caller'

El método suspender.suspendOnReturnedPromise(func)

• si func es WebAssembly.Function , entonces afirma que su tipo de función es de la forma [t*] -> [externref] y devuelve WebAssembly.Function con el tipo de función [t*] -> [externref] ;
• de lo contrario, afirma que func es un Function y devuelve un Function .

En cualquier caso, la función devuelta por suspender.suspendOnReturnedPromise(func) hace lo siguiente cuando se llama con argumentos args :

1. Permite que result sea ​​el resultado de llamar a func(args) (o cualquier trampa o excepción lanzada)
2. Si result no es una Promesa devuelta, entonces devuelve (o vuelve a lanzar) result
3. Trampas si el estado de suspender no está activo [ caller ] para algunos caller
4. Permite que frames sean los marcos de pila desde caller
5. Captura si hay marcos de funciones que no se pueden suspender en frames
6. Cambia el estado de suspender a Suspendido
7. Devuelve el resultado de result.then(onFulfilled, onRejected) con las funciones onFulfilled y onRejected que hacen lo siguiente:
   
   
   
   1. Afirma que el estado de suspender está suspendido (debe estar garantizado)
   
   
   2. Cambia el estado de suspender a Activo [ caller' ], donde caller' es el llamador de onFulfilled / onRejected
   
   
   3. 
      
      
      • En el caso de onFulfilled , convierte el valor dado en externref y lo devuelve a frames
      
      
      
      • En el caso de onRejected , arroja el valor dado hasta frames como una excepción de acuerdo con la API de JS de la propuesta de manejo de excepciones
      
      
      
   
   

Una función se puede suspender si se

• definido por un módulo WebAssembly,
• devuelto por suspendOnReturnedPromise ,
• devuelto por returnPromiseOnSuspend ,
• o generado mediante la creación de una función de host para una función suspendible

Es importante destacar que las funciones escritas en JavaScript no se TC39 , y las funciones del host (excepto las pocas enumeradas anteriormente) no se

Implementación

La siguiente es una estrategia de implementación para esta propuesta.
Asume el soporte del motor para el cambio de pila, que por supuesto es donde se encuentran los principales desafíos de implementación.

Hay dos tipos de pilas: una pila de host (y JavaScript) y una pila de WebAssembly. Cada pila de WebAssembly tiene un campo de suspensión llamado suspender . Cada hilo tiene una pila de hosts.

Cada Suspender tiene dos campos de referencia de pila: uno llamado caller y otro llamado suspended .

• En el estado Inactivo , ambos campos son nulos.
• En el estado Activo , el campo caller referencia a la pila (suspendida) de la persona que llama, y ​​el campo suspended es nulo
• En el estado Suspendido , el campo suspended referencia a la pila de WebAssembly (suspendida) actualmente asociada con la suspensión, y el campo caller es nulo.

suspender.returnPromiseOnSuspend(func)(args) es implementado por

1. Verificando que suspender.caller y suspended.suspended son nulos (trapping de lo contrario)
2. Dejando que stack sea ​​una pila de ensamblaje web recién asignada asociada con suspender
3. Cambiar a stack y almacenar la pila anterior en suspender.caller
4. Dejando que result sea ​​el resultado de func(args) (o cualquier trampa o excepción lanzada)
5. Cambiar a suspender.caller y establecerlo en nulo
6. Liberando stack
7. Devolver (o volver a tirar) result

suspender.suspendOnReturnedPromise(func)(args) es implementado por

1. Llamando a func(args) , atrapando cualquier trampa o excepción lanzada
2. Si result no es una Promesa devuelta, devolver (o volver a lanzar) result
3. Verificando que suspender.caller no sea nulo (trapping de lo contrario)
4. Sea stack la pila actual
5. Si bien stack no es una pila de WebAssembly asociada con suspender :
   
   
   
   • Comprobando que stack es una pila de WebAssembly (de lo contrario, se capturará)
   
   
   • Actualizando stack para que sea stack.suspender.caller
   
   
6. Cambiar a suspender.caller , establecerlo en nulo y almacenar la pila anterior en suspender.suspended
7. Devolviendo el resultado de result.then(onFulfilled, onRejected) con las funciones onFulfilled y onRejected implementadas por
   
   
   
   1. Cambiar a suspender.suspended , establecerlo en nulo y almacenar la pila anterior en suspender.caller
   
   
   2. 
      
      
      • En el caso de onFulfilled , convertir el valor dado a externref y devolverlo
      
      
      
      • En el caso de onRejected , volviendo a arrojar el valor dado
      
      
      
   
   

La implementación de la función generada al crear una función de host para una función suspendible se cambia para cambiar primero a la pila de host del hilo actual (si no está ya en ella) y, por último, volver a la pila anterior.