既存のWebAssemblyスレッドの提案は、wasmコンパイルされたプログラムが複数のシステムスレッドを利用できるようにすることに焦点を当てています。 これは、CPUを集中的に使用するタスクに非常に役立つ機能です。 しかし、IOを集中的に使用し、システムスレッドよりもはるかに軽量なコルーチンで解決できる、大きなクラスの問題があります。 すでにマルチスレッドをサポートしている言語に最近追加されたRustasync-waitは、そのようなニーズの良い例です。 async-awaitの問題は、アプリケーションコードを記述するためのまったく異なる方法と、異なるコンパイル手法が必要になることです。 反対に、Goの人気の主な理由の1つは、ランタイムによってコルーチンとして実行されている間、開発者にとって実際のスレッドのように見えるゴルーチンです。
WebAssemblyは、Goスレッドモデルの利点を、wasmにコンパイルできる実質的にすべてのマルチスレッドアプリケーションにもたらす独自の立場にあると思います。 アイデアは、コンパイルされたプログラムがグリーンスレッドを活用するために変更する必要がないということです。これは、それを実行する方法のホストの選択になります。
WebAssemblyのもう1つの重要な機能は、決定論的実行です。 グリーンスレッドを使用すると、マルチスレッドターゲットに決定論的実行モードを実装するのは簡単です。
この機能のストローマン名は_Wasmroutines_です。
https://github.com/WebAssembly/design/issues/126やhttps://github.com/WebAssembly/design/issues/1252などの「ネイティブwasmスレッド」に関連する問題をいくつか見つけましたが、最終的にはwasmになる可能性があるものと見なされますが、現時点ではかなり理論的です。
_シングルシステムスレッドの実装_は比較的少ない労力で実行でき(たとえば、通常の線形メモリを使用できます)、別の設計として持つ価値のある多くの価値(変更なしでマルチスレッドプログラムを実行するなど)を提供すると思います。提案。
Asyncifyに興味があるかもしれません。これは、新しいWebAssembly機能を必要とせずに、WebAssemblyで実行を一時停止および再開したり、スタックを切り替えたりするために使用できるコード変換ツールです。 このソリューションにはオーバーヘッドがあり、代数効果ハンドラーを使用したスタック切り替えの新しいメカニズムを提案する計画があると思います。これは本質的に再開可能な例外です。 例外の提案は、この将来の方向性を念頭に置いて設計されています。
@tlivelyに感謝します。 Asyncifyは、私の問題に対するクールな一時的な解決策のように見えます。 その上でプロトタイプを作成してみます。 理想的には、ホストが提供する機能のみを使用して、変更を加えずにマルチスレッドWebAssemblyプログラムを実行したいと思います。
@mfateevあなたが正しいと思います。 コルーチンをサポートすることには大きな価値があります。 代数効果のフレームワーク内で例外処理とコルーチンを統合することについては、すでにいくつかの予備的な議論がありました。 これは古い例外処理の提案で説明されており、 @ rossbergには新しい例外処理の提案と互換性のある新しいデザイン思考があると思います。
@rossbergが継続のために提案された設計を提示するビデオが
ビデオをありがとう。 「スタックスイッチング」は、多数のユースケースを可能にする非常に強力な抽象化です。 サポートされるのを楽しみにしています。
私の角度は、wasmバイトコードに新しい機能を提案しないという点でどういうわけか異なります。 私は、atomic.wait / notifyおよびその他のアトミック操作を使用するマルチスレッドコードに決定論的な実行を提供することを検討しています。 基本的にコルーチンベースであるが、WebAssemblyアプリケーションにとってマルチスレッドランタイムのように見える特別なホスト実行モードを指定できると思います。
最も参考になるコメント
@rossbergが継続のために提案された設計を提示するビデオが
https://youtu.be/pq-Pa2Fj4nE?t=3231