Design: Mémoire partagée et atomes

Ma question est la suivante : est-ce que tout le monde est d'accord pour copier les limitations du thread principal dans cette spécification vers WASM ?

@chicoxyzzy , il y a eu une longue discussion sur sab+wasm ici : https://github.com/tc39/ecmascript_sharedmem/issues/59

@taisel , maintenant je suis pédant, mais quand même: les "limitations du thread principal" ne font pas techniquement partie de cette spécification. La spécification permet à certains threads de refuser de bloquer (selon des critères choisis par l'implémentation), et cette facilité est clairement motivée par les threads principaux des navigateurs, mais une utilisation de JS + mémoire partagée dans un autre cadre que le navigateur n'a pas besoin de avoir cette limitation. Je ne vois pas comment wasm est dans une situation différente. De plus, je pouvais voir certains types de travailleurs, comme SharedWorkers, utiliser la mémoire partagée, mais ne pas être autorisés à bloquer.

En effet, pour le TC39, exiger des navigateurs qu'ils autorisent le blocage sur le thread principal ne mènerait à rien de fructueux, seulement à des conflits, et mettrait probablement en danger la mise en œuvre de l'ensemble de la proposition de mémoire partagée. Ce que nous avons maintenant est une extension assez conservatrice du langage et des navigateurs qui s'intègre dans l'écosystème Web existant. Nous savons que le proxy peut résoudre certains problèmes ; nous savons que le blocage "asymétrique" (les travailleurs bloquent mais pas le thread principal) peut résoudre d'autres problèmes ; nous devons acquérir une certaine expérience avec cela pour savoir où se trouvent les vrais points douloureux, et nous pourrons ensuite voir comment les résoudre. Essayer d'imposer le blocage sur le thread principal est l'option nucléaire, à ce stade.

@lars-t-hansen Oui, et j'ai réitéré cette limitation douce pour encourager la discussion.

Il y a toujours un groupe de personnes qui, selon moi, voudraient que le portage soit aussi indolore que possible, et je ne connais pas beaucoup de concessions que le comité WASM pourrait vouloir leur faire.

Pour ajouter à ce qui précède, la section WebAssembly de Discussion.md contient un bon résumé de la discussion sab+wasm.

La proposition de filetage initiale est conçue pour correspondre au comportement des travailleurs SAB +, il est donc peu probable qu'elle fasse bouger le bateau ici. Nous avons parlé d'avoir des threads "pur wasm", qui n'ont pas de contexte JavaScript, mais nous avons décidé que cela était mieux abordé une fois que nous atteignions la parité des fonctionnalités avec JavaScript + SAB.

De plus, la spécification html est désormais intégrée au blocage WRT de la Atomics.wait ).