Design: soporte asincrónico / de promesa

Creado en 7 ene. 2018 · 7Comentarios · Fuente: WebAssembly/design

Muchas bibliotecas de JavaScript son asincrónicas y todavía no he visto que WebAssembly admita promesas.
Para escribir fácilmente aplicaciones de rendimiento que aprovechen el ecosistema JS, sugeriría agregar soporte de promesas en funciones importadas.

Por ejemplo, esto debería funcionar:

const importObject = { 
  returnOneAsync: () => new Promise(done => done(1)) 
};

extern "C" int returnOneAsync();

int main(){
  int x = returnOneAsync(); // should suspend main until promise resolved.
  return x+x;
}

Fuente

nikhedonia

👍5

Comentario más útil

Creo que no entiende el modelo computacional de la web. JavaScript no es multiproceso, por lo que suspender un cálculo detendría el motor y, de hecho, todo el renderizador que lo aloja. La página se congelaría y no se podría ejecutar ningún otro código (aparte de los trabajadores separados). Necesitaría una forma de reificar y luego restaurar las continuaciones para hacer volar la suspensión, que no es algo que los motores puedan hacer actualmente.

rossberg en 9 ene. 2018

👍6

Todos 7 comentarios

Cualquier soporte de las promesas de JS debería ser parte de la propuesta de enlaces de host de JS .

Pero me temo que no puede funcionar como sugiere su ejemplo, ya que eso requeriría que C mismo entendiera la ejecución y suspensión asíncronas, lo cual no es así. Además, no hay nada asincrónico en su ejemplo, solo crea una promesa, por lo que el código equivalente ni siquiera se suspendería en JS, sino que solo produciría una cadena como "[object Promise][object Promise]" .

rossberg en 8 ene. 2018

Además, no hay nada asincrónico en su ejemplo

Bueno, el valor no está disponible hasta que eventloop procesa la promesa.
La idea es suspender la ejecución del motor de ensamblaje web hasta que el valor esté disponible.
El ejemplo proporcionado es, por supuesto, muy trivial. Un ejemplo más concreto podría ser realizar una consulta de base de datos a través de la red: getAgeOf: (name) => db.find({name}).then(x=>x.age)

C en sí mismo para comprender la ejecución y suspensión asíncronas, que no

Eso es incorrecto. Hay varias implementaciones de co-rutinas para C.
Además, LLVM-5.0 y versiones posteriores admiten corrutinas y async / await.

https://llvm.org/docs/Coroutines.html

Y como un apéndice a C ++ 17 está el coroutine-ts que se ha implementado desde clang-5.0.
Hay un par de bibliotecas experimentales que ya lo usan:
https://github.com/lewissbaker/cppcoro#generator

nikhedonia en 8 ene. 2018

Las implementaciones de corrutinas en C no interoperan mágicamente con el bucle de eventos de JavaScript. Además, generalmente se basan en un comportamiento específico de la implementación. Para implementar de manera confiable y portátil algo como coroutines o async, necesitaría una forma de continuaciones delimitadas en el lenguaje. Lo más cercano que C tiene para ofrecer es longjmp, que no es suficiente y actualmente no se puede implementar en Wasm (con Emscripten, longjmp se implementa en JS con excepciones de JS). Wasm actualmente no puede expresar suspensión, aunque hay planes para agregar algo en este sentido eventualmente. Las corrutinas de C ++ aún no son estándar y no pueden ser manejadas por Emscripten AFAICT.

rossberg en 8 ene. 2018

👍4

Veo de donde vienes.
Creo que no he expresado mi idea lo suficientemente bien.
No estoy sugiriendo admitir corutinas ni promesas en C / C ++ o darme cuenta de eso en el código de bytes wasm.

Pero me temo que no puede funcionar como sugiere su ejemplo, ya que eso requeriría que el propio C entienda la ejecución y suspensión asíncronas, lo cual no es así.

¿Por qué cree que es necesario que C comprenda la ejecución asíncrona?

¿Cuál es la dificultad técnica para suspender el motor de ejecución de wasm hasta que se resuelva la promesa?

Entiendo que se supone que wasm se compila con anticipación en x86, pero eso no significa que no tenga control sobre el flujo de ejecución.
Una forma común de detener la ejecución es utilizar interrupciones de hardware y llamadas al sistema como ptrace; así es como funciona el depurador. Sabemos exactamente qué funciones se importan y podríamos inyectar los códigos de operación apropiados (x86) para lograrlo. Aunque esto ralentizará la ejecución de esas funciones, no importaría ya que estamos esperando en esos casos que la promesa se resuelva de todos modos.
Así es como implementamos suspender / depurar / reanudar en nuestro C ++ JIT / AoT basado en LLVM.

Supongo que este problema debería archivarse en el repositorio de enlaces de host ...

nikhedonia en 9 ene. 2018

rossberg en 9 ene. 2018

👍6

relacionado: https://github.com/WebAssembly/design/issues/720

wanderer en 10 ene. 2018

Creo que no entiende el modelo computacional de la web. JavaScript no es multiproceso, por lo que suspender un cálculo detendría el motor y, de hecho, todo el renderizador que lo aloja. La página se congelaría y no se podría ejecutar ningún otro código (aparte de los trabajadores separados). Necesitaría una forma de reificar y luego restaurar las continuaciones para hacer volar la suspensión, que no es algo que los motores puedan hacer actualmente.

Exactamente, wasm debería ejecutarse dentro de los trabajadores, ya que ambos se crearon para tareas de cálculo en lugar de tratar con la interfaz de usuario.