Design: Wasmroutines

Créé le 30 déc. 2019  ·  5Commentaires  ·  Source: WebAssembly/design

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.

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

Tous les 5 commentaires

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).

https://youtu.be/pq-Pa2Fj4nE?t=3231

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.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

JimmyVV picture JimmyVV  ·  4Commentaires

thysultan picture thysultan  ·  4Commentaires

void4 picture void4  ·  5Commentaires

konsoletyper picture konsoletyper  ·  6Commentaires

jfbastien picture jfbastien  ·  6Commentaires