La proposition de threads WebAssembly existante
Je pense que WebAssembly est idéalement positionné pour apporter l'avantage du modèle de thread Go à pratiquement n'importe quelle application multithread qui peut être compilée en wasm. L'idée est que le programme compilé n'a pas besoin de changer pour tirer parti des threads verts, cela devient le choix de l'hôte sur la façon de l'exécuter.
Une autre caractéristique importante de WebAssembly est l'exécution déterministe. Avec les threads verts, il devrait être simple d'implémenter un mode d'exécution déterministe pour les cibles multithread.
Le nom de l'homme de paille pour la fonctionnalité est _Wasmroutines_.
J'ai trouvé quelques problèmes liés aux "fils wasm natifs" comme https://github.com/WebAssembly/design/issues/126 et https://github.com/WebAssembly/design/issues/1252 mais il semble qu'ils le soient considéré comme quelque chose qui pourrait finir par devenir, mais assez théorique à ce stade.
Je pense que _l'implémentation d'un seul thread système_ peut être effectuée avec un effort relativement faible (par exemple, elle pourrait utiliser la mémoire linéaire normale) et fournirait beaucoup de valeur (comme l'exécution de n'importe quel programme multithread sans modification) qui vaut la peine d'avoir une conception distincte proposition.
Vous pourriez être intéressé par Asyncify , qui est un outil de transformation de code qui peut être utilisé pour suspendre et reprendre l'exécution ou changer de pile dans WebAssembly sans nécessiter de nouvelles fonctionnalités WebAssembly. Cette solution a des frais généraux, et je pense qu'il est prévu de proposer un nouveau mécanisme de commutation de pile à l'aide de gestionnaires d'effets algébriques, qui ne sont essentiellement que des exceptions récupérables. La proposition d'exceptions a été conçue avec cette orientation future à l'esprit.
Merci @tlively. Asyncify ressemble à une solution palliative sympa pour mon problème. Je vais essayer de prototyper dessus. Idéalement, je voudrais exécuter n'importe quel programme WebAssembly multithread sans aucune modification en utilisant uniquement les fonctionnalités fournies par l'hôte.
@mfateev je pense que tu as raison; il serait très utile de soutenir les coroutines. Il y a déjà eu des discussions préliminaires sur l'unification de la gestion des exceptions et des coroutines dans le cadre des effets algébriques. Ceci est discuté dans l'ancienne proposition de gestion des exceptions, et je pense que @rossberg a une conception plus récente compatible avec la nouvelle proposition de gestion des exceptions.
Il y a une vidéo où @rossberg présente le design proposé pour les suites (mentionné par @lukewagner).
Merci pour la vidéo. Le "stack Switching" est une abstraction très puissante qui permettrait le grand nombre de cas d'utilisation. Dans l'attente qu'il soit soutenu.
Mon angle est quelque peu différent en ne proposant aucune nouvelle fonctionnalité dans le bytecode wasm. Je cherche à fournir l'exécution déterministe pour tout code multithread qui utilise atomic.wait/notify et d'autres opérations atomiques. Je pense que nous pouvons spécifier un mode d'exécution hôte spécial qui est essentiellement basé sur la coroutine, mais qui ressemble à un runtime multithread pour une application Web Assembly.
Commentaire le plus utile
Il y a une vidéo où @rossberg présente le design proposé pour les suites (mentionné par @lukewagner).
https://youtu.be/pq-Pa2Fj4nE?t=3231