Design: support async / promesse

Créé le 7 janv. 2018 · 7Commentaires · Source: WebAssembly/design

De nombreuses bibliothèques JavaScript sont asynchrones et je n'ai pas encore vu que WebAssembly prend en charge les promesses.
Afin d'écrire facilement des applications performantes qui exploitent l'écosystème JS, je suggère d'ajouter la prise en charge des promesses dans les fonctions importées.

Par exemple, cela devrait fonctionner :

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;
}

Source

nikhedonia

👍5

Commentaire le plus utile

Je pense que vous comprenez mal le modèle informatique du Web. JavaScript n'est pas multithread, donc suspendre un calcul arrêterait le moteur, et en fait l'ensemble du moteur de rendu qui l'héberge. La page se figerait et aucun autre code ne pourrait s'exécuter (autre que des travailleurs séparés). Vous auriez besoin d'un moyen de réifier et de restaurer plus tard les continuations pour faire voler la suspension, ce que les moteurs ne peuvent actuellement pas faire.

rossberg le 9 janv. 2018

👍6

Tous les 7 commentaires

Toute prise en charge des promesses JS devrait faire partie de la proposition de liaisons d'hôte JS .

Mais je crains que cela ne puisse pas fonctionner comme le suggère votre exemple, car cela nécessiterait que C lui-même comprenne l'exécution et la suspension asynchrone, ce qui n'est pas le cas. De plus, il n'y a rien d'async dans votre exemple, il crée simplement une promesse, de sorte que le code équivalent ne serait même pas suspendu dans JS lui-même, mais produirait simplement une chaîne comme "[object Promise][object Promise]" .

rossberg le 8 janv. 2018

De plus, il n'y a rien d'async dans votre exemple

Eh bien, la valeur n'est pas disponible tant que la boucle d'événement n'a pas traité la promesse.
L'idée est de suspendre l'exécution du moteur d'assemblage Web jusqu'à ce que la valeur soit disponible.
L'exemple fourni est bien sûr très trivial. Un exemple plus concret serait de faire une requête de base de données sur le réseau : getAgeOf: (name) => db.find({name}).then(x=>x.age)

C lui-même pour comprendre l'exécution et la suspension asynchrone, ce qu'il ne fait pas

C'est inexact. Il existe différentes implémentations de coroutine pour C.
De plus, LLVM-5.0 et versions ultérieures prennent en charge les coroutines et async/wait.

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

Et en tant qu'addendum à C++17, il y a le coroutine-ts qui a été implémenté depuis clang-5.0.
Il existe déjà quelques bibliothèques expérimentales qui l'utilisent :
https://github.com/lewissbaker/cppcoro#generator

nikhedonia le 8 janv. 2018

Les implémentations de coroutines en C n'interagissent pas comme par magie avec la boucle d'événement de JavaScript. En outre, ils reposent généralement sur un comportement spécifique à la mise en œuvre. Pour implémenter de manière fiable et portable quelque chose comme des coroutines ou async, vous auriez besoin d'une forme de continuations délimitées dans le langage. Le C le plus proche a à offrir est longjmp, ce qui n'est pas suffisant et ne peut actuellement pas être implémenté dans Wasm lui-même (avec Emscripten, longjmp est implémenté dans JS avec des exceptions JS). Wasm ne peut actuellement pas exprimer de suspension, bien qu'il soit prévu d'ajouter quelque chose dans ce sens à terme. Les coroutines C++ ne sont pas encore standard et ne peuvent pas être gérées par Emscripten AFAICT.

rossberg le 8 janv. 2018

👍4

Je vois d'où tu viens.
Je pense que je n'ai pas assez bien exprimé mon idée.
Je ne suggère pas de prendre en charge les coroutines ni les promesses en C/C++ ou de le réaliser dans le bytecode wasm.

Mais je crains que cela ne puisse pas fonctionner comme le suggère votre exemple, car cela nécessiterait que C lui-même comprenne l'exécution et la suspension asynchrone, ce qu'il ne fait pas

Pourquoi pensez-vous qu'il est nécessaire que C comprenne l'exécution asynchrone ?

Quelle est la difficulté technique de suspendre le moteur d'exécution wasm jusqu'à ce que la promesse soit résolue ?

Je comprends que wasm est censé être compilé à l'avance sur x86, mais cela ne signifie pas que vous n'avez aucun contrôle sur le flux d'exécution.
Un moyen courant d'arrêter l'exécution consiste à utiliser des interruptions matérielles et des appels système comme ptrace ; c'est ainsi que fonctionne le débogueur. Nous savons exactement quelles fonctions sont importées et nous pourrions injecter les opcodes (x86) appropriés pour accomplir cela. Bien que cela ralentisse l'exécution de ces fonctions - cela n'aurait pas d'importance car nous attendons dans ces cas que la promesse soit résolue de toute façon.
C'est ainsi que nous avons implémenté la suspension/débogage/reprise dans notre C++JIT/AoT basé sur LLVM.

Je suppose que ce problème devrait être classé dans le référentiel host-bindings ...

nikhedonia le 9 janv. 2018

rossberg le 9 janv. 2018

👍6

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

wanderer le 10 janv. 2018

Je pense que vous comprenez mal le modèle informatique du Web. JavaScript n'est pas multithread, donc suspendre un calcul arrêterait le moteur, et en fait l'ensemble du moteur de rendu qui l'héberge. La page se figerait et aucun autre code ne pourrait s'exécuter (autre que des travailleurs séparés). Vous auriez besoin d'un moyen de réifier et de restaurer plus tard les continuations pour faire voler la suspension, ce que les moteurs ne peuvent actuellement pas faire.

Exactement, wasm doit être exécuté à l'intérieur des travailleurs, car ils ont tous deux été créés pour des tâches de calcul plutôt que pour traiter l'interface utilisateur.