Design: 提案：お待ちください

優れた記事！ 私はホスト制御のサスペンションのアイデアが好きです。 @rossbergの提案では、機能効果システムについても説明しています。私は確かにそれらの専門家ではありませんが、一見すると、同じ非ローカル制御フローのニーズを満たすことができるようです。

「上記のことを考えると、自然な実装は、一時停止したときにスタックをコピーすることです。」 これは実行スタックに対してどのように機能しますか？ ほとんどのJITエンジンはJSとwasmの間でネイティブC実行スタックを共有していると思います。そのため、このコンテキストで保存と復元が何を意味するのかわかりません。 この提案は、wasm実行スタックを何らかの方法で仮想化する必要があることを意味しますか？ このようなCスタックの使用を回避するIIUCは、Pythonが同様のことを行おうとしたときにかなり注意が必要でした： https：//github.com/stackless-dev/stackless/wiki。

私は@ sbc100と同様の心配を共有します。 スタックのコピーは、特にVMにまだGCが実装されていない場合、本質的に非常に難しい操作です。

@ sbc100

この提案は、wasm実行スタックを何らかの方法で仮想化する必要があることを意味しますか？

私は専門家ではないので、これはVMの実装者に任せなければなりません。 そして、私はスタックレスpythonへの接続を理解していませんが、おそらく接続を理解するのに十分なものが何であるかわかりません、ごめんなさい！

しかし、一般的には、さまざまなコルーチンアプローチは、スタックポインタを低レベルで操作することによって機能します。 これらのアプローチは、ここでのオプションかもしれません。 このようなアプローチの一部としてスタックをコピーする必要がある場合でも、このコンテキストでは許容できるオーバーヘッドがあることを指摘したいと思います。

（これらのアプローチがwasm VMで機能するかどうかは定かではありません。はいまたはいいえの場合は実装者からの連絡を期待し、より良いオプションがあるかどうかを確認します！）

@lachlansneff

GCが物事を簡単にすることの意味を詳しく説明していただけますか？ 私はフォローしません。

@kripken GCには、多くの場合（常にではありませんが）スタックをウォークする機能があります。これは、新しいスタックを指すようにスタック上のポインターを書き換える必要がある場合に必要です。 おそらく、JSCについてもっと知っている人は、これを確認または拒否できます。

@lachlansneff

ありがとう、今あなたが言っていることがわかります。

これを行うために、スタックを完全に歩く（各ローカルを完全に識別するなど）必要があることはお勧めしません。 （他の可能なアプローチについては、低レベルのコルーチン実装方法に関する私の最後のコメントのリンクを参照してください。）

提案の「スタックをコピーする」という用語をお詫びします。あなたと@ sbc100のフィードバックに基づくと、十分に明確ではなかったようです。 繰り返しになりますが、特定のVM実装アプローチを提案する必要はありません。 スタックのコピーが何らかのアプローチで必要な場合、それは速度の問題にはならないということを言いたかっただけです。

特定の実装アプローチを提案するのではなく、VMの人々から、これがどのように実行できると考えているかを聞いてみたいと思います。

この提案を見てとても興奮しています。 Lucetにはしばらくの間yieldとresumeの演算子があり、Rustホスト環境で実行されている非同期コードと対話するためにこれらを正確に使用しています。

私たちの設計はすでにWasm実行用に別のスタックを維持することを約束しているため、これをLucetに追加するのはかなり簡単でしたが、そうでないVMでは実装上の問題が発生する可能性があると想像できました。

この提案は素晴らしいですね！ 私たちは、wasmer-jsで非同期コードを管理するための良い方法を少しの間試みてきました（ブラウザーのコンテキストではVM内部にアクセスできないため）。

特定の実装アプローチを提案するのではなく、VMの人々から、これがどのように実行できると考えているかを聞いてみたいと思います。

おそらく、非同期関数にコールバック戦略を使用するのが、物事を順調に進めるための最も簡単な方法であり、言語に依存しない方法かもしれないと思います。

.awaitは、$ wasm-bindgen-futuresを使用してRust関数内のJsPromiseで呼び出すことができるようです。 ここで提案されているawait命令なしで、これはどのように機能しますか？ 私の無知をお詫び申し上げます。wasm内でfetchを呼び出すソリューションを探しており、Asyncifyについて学習していますが、Rustソリューションの方が簡単であることがわかります。 私がここで欠けているものは何ですか？ 誰かが私にそれを明確にすることができますか？

私はこの提案に非常に興奮しています。 この提案の主な利点は、wasmのPOVと同期するAPIを構築できるため、そのシンプルさです。また、コールバックやasync / awaitについて明示的に考えることなく、アプリケーションの移植がはるかに簡単になります。 これにより、 WASMおよびWebGPUベースの機械学習を単一のネイティブAPIを使用してネイティブwasm vmsにもたらし、Webとネイティブの両方で実行できるようになります。

議論する価値があると思うことの1つは、待機を呼び出す可能性のある関数のシグネチャです。 次の関数があると想像してください

int test() {
   await();
   return 1;
}

対応する関数のシグネチャは() => i32です。 新しい提案では、テストへの呼び出しはi32またはPromise<i32>のいずれかを返す可能性があります。 新しい署名を静的に宣言するようにユーザーに依頼するのは難しいことに注意してください（コード移植のコストがあり、呼び出しが待機していることがわからない関数内の間接呼び出しである可能性があるため）。

実行時に待機が許可されていることを示すために、エクスポートされた関数（非同期呼び出しなど）に個別の呼び出しモードを設定する必要がありますか？

用語的には、提案された操作は、オペレーティングシステムのyield操作のようなものです。 OS（この場合はwasm VM）に制御を渡して、syscallがfinsihになるのを待つためです。

この提案を正しく理解していれば、JSのawaitはasync関数でのみ使用できるという制限を取り除くこととほぼ同じだと思います。 つまり、wasm側でwaitrefをexternrefにすることができ、 await命令ではなく、インポートされた関数$await : [externref] -> []を使用できます。JS側ではインポートする関数としてfoo(promise) => await promiseを指定できます。 逆に、 async関数の外部のPromiseでawaitを実行したいJSコードの場合、 awaitを呼び出すだけのwasmモジュールにそのpromiseを提供できます。入力に。 それは正しい理解ですか？

@RossTateそうではありません、AIUI。 wasmコードはawaitを約束することができます（これをpromise1と呼びます）が、wasmの実行のみが生成され、JSは生成されません。 wasmコードは、JS呼び出し元に別のpromise（ promise2と呼びます）を返します。 promise1が解決されると、wasmの実行が続行されます。 最後に、そのwasmコードが正常に終了すると、 promise2はwasm関数の結果で解決されます。

@tqchen

実行時に待機が許可されていることを示すために、エクスポートされた関数（非同期呼び出しなど）に個別の呼び出しモードを設定する必要がありますか？

興味深い-メリットはどこにあると思いますか？ あなたが言ったように、一般的な移植の状況では、エクスポートがawaitを実行するかどうかを確認する方法は実際にはないので、せいぜい時々しか使用できませんでした。 これはVMの内部に役立つでしょうか？

明示的な宣言があると、ユーザーが意図を明確に示すことができ、ユーザーの意図が非同期を実行する呼び出しを行っていない場合、VMは適切なエラーメッセージをスローする可能性があります。

また、ユーザーのPOVから、コードの記述の一貫性が高まります。 たとえば、testがawaitを呼び出さなくても、ユーザーは次のコードを記述でき、システムインターフェイスはPromise.resolve（test（））を自動的に返します。

await inst.exports_async.test();

.awaitは、$ wasm-bindgen-futuresを使用してRust関数内のJsPromiseで呼び出すことができるようです。 await命令なしで、これはどのように機能しますか？ 私の無知をお詫び申し上げます。wasm内でfetchを呼び出すソリューションを探しており、Asyncifyについて学習していますが、Rustソリューションの方が簡単であることがわかります。 誰かが私にそれを明確にすることができますか？

@malbarbo似たようなユースケースにもかかわらず、2つの間にほとんど重複はありません。 Rustが行っているのは、本質的に完全なコルーチンであり、他のリンクされた提案の範囲内にあります。

より柔軟性がありますが、言語とコードベースの両方からより多くの関与とオーバーヘッドが必要です-ネイティブにasync関数の概念を持ち、コールチェーン内のすべての関数をそのようにマークする必要があります。

この提案が代わりに達成しようとしているのは、ホストが提供するシステムコールを待つ方法です。非同期であるのは実装の詳細にすぎないため、このような関数は、既存のコードベースのどこからでも下位互換性のある方法で呼び出すことができます。アプリ全体の動作を書き直す必要があります。 （例として、C / C ++ / Rustを含むソース言語が同期的に利用可能であると期待しているファイルI / Oがありますが、Webなどでは利用できません。）

つまり、Webには非同期APIしかないため、現在同期OS API（ std::fsなど）を使用することはできません。 しかし、この提案では、同期OS APIを使用できます。内部的にはPromisesを使用しますが、Rustと同期しているように見えます。

この提案が実装されたとしても、 wasm-bindgen-futuresは引き続き存在し、別のユースケース（ async関数を実行する）を処理するため、引き続き有用です。 また、 async関数は、簡単に並列化できるので便利です。

@RossTateあなたの提案は、「検討されている代替アプローチ」で取り上げられているものと非常に似ているようです。

私たちが検討したもう1つのオプションは、「Promiseが返された場合、このインポートは一時停止する必要があります」と言うようにインポートをマークすることです。 JS側またはwasm側のいずれかで、それらをマークする方法についてさまざまなオプションを検討しましたが、正しいと感じるものは見つかりませんでした。 たとえば、JS側でインポートをマークすると、wasmモジュールは、インポートが到着するリンクステップまで、インポートの呼び出しが一時停止するかどうかを認識しません。 つまり、インポートと一時停止の呼び出しは「混合」されます。 最も簡単なことは、このための新しい命令、awaitを用意することであるように思われます。これは、待機について明示的です。 理論的には、このような機能はWebの外部でも役立つ可能性があるため（前述の注を参照）、すべての人に指示を与えることで、全体的な一貫性を高めることができます。

開始関数はどのように処理されますか？ 静的に待機を禁止しますか、それともWasmインスタンス化と何らかの形で相互作用しますか？

@Pauanこれについては特に取り上げませんでしたが、 startでもawaitを許可することを妨げるものは何もないと思います。 この場合、 instantiate{Streaming}から返されたPromiseは、start関数が完全に実行を終了したときに自然に解決/拒否されますが、唯一の違いは、 await edpromiseを待機することです。

とは言うものの、今日と同じ制限が適用され、今のところ、エクスポートされたメモリなどへのアクセスが必要な場合にはあまり役に立ちません。

@RReverser同期new WebAssembly.Instance （ワーカーで使用される）ではどのように機能しますか？

スタートについての興味深いポイント@Pauan ！

ええ、同期インスタンス化の場合は危険なようですawaitが許可されている場合、一時停止中に誰かがエクスポートを呼び出した場合は奇妙です。 await禁止すると、最も単純で安全な場合があります。 （おそらく、一貫性を保つための非同期開始でも、それを妨げる重要なユースケースはないようです。さらに検討する必要があります。）

（これは労働者に使用されます）？

うーん良い点。 ワーカーで使用する必要はないと思いますが、このAPIはすでに存在するため、Promiseを返す可能性がありますか？ これは、さまざまなライブラリのコンストラクターからthenablesを返すための半人気の新しいパターンであると考えていますが、標準のAPIでこれを行うのが良いかどうかはわかりません。

start （トラッピングのように）許可しないのが今のところ最も安全であり、何かが変更された場合は、将来的に下位互換性のある方法でいつでも変更できることに同意します。

何かを見逃したかもしれませんが、WASMの実行がawait命令で一時停止され、PromiseがJSに返され、JSがPromiseを待たずにWASMにコールバックするとどうなるかについての議論はありません。

それは有効なユースケースですか？ そうである場合、「メインループ」アプリケーションがブラウザに手動で譲ることなく入力イベントを受信できるようにする可能性があります。 代わりに、彼らはすぐに解決される約束を待つことによって譲歩することができました。

キャンセルはどうですか？ これはJSPromiseには実装されておらず、これによりいくつかの問題が発生します。

@Kangz

何かを逃したかもしれませんが、WASMの実行がawait命令で一時停止され、PromiseがJSに返され、JSがPromiseを待たずにWASMにコールバックするとどうなるかについての議論はありません。

それは有効なユースケースですか？ そうである場合、「メインループ」アプリケーションがブラウザに手動で譲ることなく入力イベントを受信できるようにする可能性があります。 代わりに、彼らはすぐに解決される約束を待つことによって譲歩することができました。

現在のテキストはおそらくそれについて十分に明確ではありません。 最初の段落については、はい、許可されています。「説明」セクションを参照してください： It is ok to call into the WebAssembly instance while a pause has occurred, and multiple pause/resume events can be in flight at once.

2番目の段落では、いいえ-イベントを早く取得することはできません。また、JSにPromiseをそれよりも早く解決させることはできません。 別の方法で物事を要約してみましょう：

• wasmがPromiseAで一時停止すると、呼び出されたものに戻って終了し、新しいPromiseBを返します。
• Promise Aが解決すると、Wasmが再開します。 これは通常の時間に発生します。つまり、JSイベントループではすべてが正常です。
• wasmが再開し、実行が終了した後、PromiseBが解決されます。

したがって、特にPromiseBはPromiseAの後で解決する必要があります。JSが取得できるよりも早くPromiseAの結果を取得することはできません。

別の言い方をすれば、このプロポーザルの動作は、Asyncify +プロミスを使用するJSによってポリフィルすることができます。

@RReverser 、それらは同じではないと思いますが、最初に何かを明確にする必要があると思います（まだ明確にされていない場合は、それを見逃して申し訳ありません）。

JSから同じスタック上の同じwasmインスタンスへの複数の呼び出しが同時に発生する可能性があります。 awaitがインスタンスによって実行された場合、どの呼び出しが一時停止され、promiseが返されますか？

2番目の段落では、いいえ-イベントを早く取得することはできません。また、JSにPromiseをそれよりも早く解決させることはできません。

申し訳ありませんが、私の質問は明確ではなかったと思います。 現在、C ++の「メインループ」アプリはemscripten_set_main_loopを使用しているため、フレーム関数を実行するたびに、制御がブラウザーに戻され、入力またはその他のイベントを処理できます。

この提案では、「メインループ」アプリを翻訳するには次のように機能するはずです。 （JSイベントループはよくわかりませんが）

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM(
    new Promise((resolve, reject) => {
      setTimeout(0, () => resolve());
    })
  ))
}

@Kangzはい、うまくいくはずです（setTimeoutコードの引数の順序に小さな問題があり、単純化できる場合を除きます）：

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM_WAITREF(
    return new Promise(resolve => setTimeout(resolve));
  ));
}

JSから同じスタック上の同じwasmインスタンスへの複数の呼び出しが同時に発生する可能性があります。 インスタンスによってawaitが実行された場合、どの呼び出しが一時停止され、promiseが返されますか？

最も内側のもの。 必要に応じて残りを調整するのはJSラッパーの仕事です。

@Kangz申し訳ありませんが、その前にあなたを誤解しました。 はい、 @ RReverserが言ったように、それは機能するはずです。これは、ここでの使用目的の良い例です。

あなたが言ったように、それはAsyncifyでポリフィル可能であり、実際、 __builtin_awaitをemscripten_sleep(0)の呼び出しに置き換えることで今日のAsyncifyと同じコードと同等です（これはsetTimeout(0)を実行します） 。

明確化してくれてありがとう、 @ RReverser 。 説明を言い換えると、インスタンス自体ではなく、インスタンスへの（最新の）呼び出しが一時停止すると言うのが役立つと思います。

その場合、これは次の2つのプリミティブ関数をJSに追加するのとほぼ同じように聞こえます： promise-on-await(f)とawait-for-promise(p) 。 前者はf()を呼び出しますが、 f()の実行中に$＃$ await-for-promise(p) $＃$が呼び出された場合、代わりにpが解決した後に実行を再開する新しいPromiseを返しますそして、その実行が完了すると、それ自体が解決されます（または、 await-for-promiseを再度呼び出します）。 await-for-promiseへの呼び出しが複数のpromise-on-awaitのコンテキスト内で行われた場合、最新のものはPromiseを返します。 await-for-promise promise-on-awaitの外部で行われると、何か悪いことが起こります（インスタンスのstartコードがawaitを実行する場合と同じように）。

それは理にかなっていますか？

@RossTateそれは非常に近いです、はい、そして一般的な考えを捉えています。 （しかし、あなたが言ったように、これをポリフィルするために使用することができず、特定のwasm / JS境界処理が欠落しているため、ほぼ同等です。）

そのテキストを言い換える提案をありがとう。 私はここでの議論からそのようなメモのリストを保持しています。 （最初の投稿に適用する価値があるかどうかはわかりません。時間の経過とともに変更しないほうが混乱が少ないようです。）

@RossTateおもしろい...私はこれが好きです！ これにより、呼び出しの非同期性が明示的になり（非同期の可能性のある呼び出しには、 promise-on-awaitが必要です）、Wasmを変更する必要はありません。 また、Wasmを中央から削除すると、（ある程度）意味があります。 promise-on-awaitがawait-for-promiseを直接呼び出すと、 Promiseが返されます。

@kripkenなぜこれが違うのか、もっと詳しく教えていただけますか？ ここでWasm / JSの境界が重要である理由がよくわかりません。

@binji私は、JSのそのような関数がwasmに同様のことをさせないことを意味しました。 それらをwasmからのインポートとして呼び出すことは機能しません。 再開可能な方法でwasmを境界などに出口にする方法はまだ必要ですよね？

@kripkenそうですね、その時点でawait-for-promiseインポートはWasm組み込みのように機能する必要があると思います。

私の考えでは、wasmにawait命令を追加する代わりに、そのようなモジュールは代わりにawait-for-promiseをインポートしてそれを呼び出します。 同様に、エクスポートされた関数を変更する代わりに、JSコードはそれらをpromise-on-await内で呼び出します。 これは、JSプリミティブがWebAssemblyスタックを含むすべてのスタック作業を処理することを意味します。 また、より柔軟になります。たとえば、モジュールにJSコールバックを指定して、モジュールにコールバックし、内部句の代わりに外部呼び出しを一時停止できるようにすることができます。これはすべて、JSコードが選択するかどうかによって異なります。通話をpromise-on-awaitでラップするかどうか。 wasm自体に何かを変更する必要はないと思います。

@sygがこれらの潜在的なJSプリミティブについてどう考えているか聞いてみたいと思います。

ああ、ごめんなさい-私はあなたのコメント@RossTateを「私が理解していることを確認するために、このように言い換えて、それが正しい形であるかどうか教えてください」と解釈しました。具体的な提案ではありません。

考えてみると、JSフレームだけでなく、wasmも一時停止したいのですが、ホスト/ブラウザフレームもあります。 （現在の提案では、呼び出された境界の上のwasmにのみ取り組むことで、それを回避しています。）例を次に示します。

myList.forEach((item) => {
  .. call something which ends up pausing ..
});

forEachがブラウザコードに実装されている場合、それはブラウザフレームを一時停止することを意味します。 また、そのようなループの途中で一時停止し、後で再開することは、JSが実行できる新しい機能であり、通常のループでもそれが可能になるということも重要です。

for (let i of something) {
  .. call something which ends up pausing ..
}

そして、これはすべて、 async JS関数との奇妙な仕様の相互作用を持っている可能性があります。 これらはすべて、ブラウザやJSの人々との大規模な議論のようです。

また、これはコアwasm仕様にawaitとwaitrefを追加することを回避するだけですが、これらはコア仕様では何もしないため、ごくわずかな追加です。 現在の提案では、JS側ですでに99％の複雑さがあります。 そして、IIUCの提案は、wasm仕様への小さな追加と、JS側でのはるかに大きな追加とのトレードオフになります。したがって、Webプラットフォーム全体がより複雑になり、これがすべてwasmであるため不必要になります。 さらに、コアwasm仕様でawaitを定義することには、実際にはWebの外部で役立つ可能性があるという利点があります。

たぶん私はあなたの提案で何かを逃したかもしれません、もしそうならお詫びします。 全体として、コアのwasm仕様への追加を回避しようとする動機は何ですか？

これらのプリミティブはjsにとってあまり意味がないと思います。また、ブラウザーの実装よりも多くのwasm実装がこれから恩恵を受けることができると思います。 再開可能な例外（大まかに影響）がこのユースケースを満たさない理由については、まだ興味があります。

私のコメントは両方の組み合わせでした。 大まかに言えば、私は提案を純粋にJS APIの強化として言い換える方法があるかどうか（そして同様に他のホストがwasmモジュールとどのように相互作用するか）を理解しようとしています。 この演習は、wasmを本当に変更する必要があるかどうかを評価するのに役立ち、JSの人々が承認するかどうかにかかわらず、提案がJSに新しいプリミティブを密かに追加しているかどうかを判断するのに役立ちます。 つまり、インポートされたawait : func (param externref) (result externref)だけでは実行できない場合は、JSに新しい機能が追加されている可能性があります。

wasmへの変更の単純さに関しては、モジュール間の呼び出しをどうするか、エクスポートされた関数がawaitを実行できる関数へのポインターを含むGC値を返すときにどうするかなど、考慮すべきことがまだたくさんあります。通話が終了した後など。

演習に戻ると、ご指摘のとおり、wasmスタックのみをキャプチャするのには十分な理由があります。 これにより、以前の提案に戻りますが、いくつかの新しい視点で少し修正されています。 WebAssembly.instantiateAsync(moduleBytes, imports, "name1", "name2")関数をJSAPIに追加します。 moduleBytesに、いくつかのインポートと追加のインポートimport "name1" "name2" (func (param externref) (result externref))があるとします。 次に、 instantiateAsyncは、 importsで指定された値を使用して、 moduleBytesの他のインポートをインスタンス化し、概念的await-for-promiseで追加のインポートをインスタンス化します。 エクスポートされた関数がこのインスタンスから作成されると、それらはガードされ（概念的にはpromise-on-awaitによって）、このawait-for-promiseが呼び出されると、スタックを上って最初のガードを見つけ、の内容をコピーします。スタックを新しいPromiseに重ねると、すぐに返されます。 これで、上記と同じプリミティブができましたが、それらはもはやファーストクラスではなく、この制限されたパターンにより、wasmスタックのみがキャプチャされます。 同時に、パターンをサポートするためにWebAssemblyを変更する必要はありません。

考え？

@devsnek

再開可能な例外（大まかに影響）がこのユースケースを満たさない理由については、まだ興味があります。

確かに、これらはこの分野のオプションです。

@rossbergの前回のプレゼンテーションからの私の理解は、彼は最初はそのルートをたどりたいと思っていましたが、その後、コルーチンアプローチを行うために方向を変えたということです。 「問題」というタイトルのスライドを参照してください。 そのスライドの後に、コルーチンについて説明します。これは、このスペースのもう1つのオプションです。 それで、多分あなたの質問はおそらく明確にすることができる@rossbergのためのものですか？

この提案は、再開可能な例外やコルーチンほど多くの電力を必要としない同期/非同期の問題を解決することに焦点を当てています。 これらは、wasmモジュールの内部の相互作用に焦点を当てていますが、wasmモジュールと外部の相互作用に焦点を当てています（同期/非同期の問題が発生する場所であるため）。 そのため、コアのwasm仕様に1つの新しい命令が必要であり、この提案のほとんどすべてのロジックがwasmJS仕様に含まれています。 そしてそれはあなたがこのような約束を待つことができることを意味します：

call $get_promise
await
;; use it!

wasmの単純さはそれ自体に役立ちますが、VMにとって何が起こっているのかが非常に明確であることも意味します。

@RossTate

つまり、インポートされたawait：func（param externref）（result externref）だけでは実行できない場合は、JSに新しい機能が追加されている可能性があります。

申し訳ありませんが、その推論には従いません。 しかし、それは私には回りくどいようです。 この提案がJSに新しい機能を追加すると思うなら、それを直接示してみませんか？ （私はそうではないと強く信じていますが、私たちが間違いを犯したことに気づいたら興味があります！）

wasmへの変更の単純さに関しては、モジュール間の呼び出しについて何をすべきかなど、考慮すべきことがまだたくさんあります。

コアwasm仕様は、モジュール間の呼び出しについて何かを述べていますか？ 私はそれがそうしていることを覚えていません、そして今私はそれを見ません。 しかし、おそらく私は何かを逃しましたか？

私の信念では、コアwasm仕様の追加は、基本的にawaitをリストすることであり、「何かを待つ」ことを意味していると言えます。それだけです。 だから私は提案にThat's it for the core wasm spec!と書いたのです。 私が間違っている場合は、コアwasm仕様でさらに追加する必要がある場所を教えてください。

推測して、いつかコアのwasm仕様に、wasmモジュールを作成してそのメソッドを呼び出すための新しい命令があるとしましょう。 その場合、 awaitは、ホスト上で外部の何かを待つことがポイントであるため、トラップにすぎないと言うと思います。

これにより、以前の提案に戻りますが、いくつかの新しい視点で少し修正されました[新しいアイデア]

そのアイデアは、提案のAlternative approaches consideredの2番目の段落と機能的に同じではありませんか？ そのようなことはできますが、なぜそれが良くないと思うのかを説明しました。

@kripkenはそれを手に入れました。 明確にするために、 awaitは、非常に実用的でエレガントな方法で提示されたユースケースを解決すると思います。 また、この勢いを利用して、デザインを少し広げることで、他のユースケースも解決できることを願っています。

@RossTateの提案は、「検討された代替アプローチ」で言及されているものと非常によく似ていると思います。 したがって、そのアプローチが却下された理由について、より詳細に議論する必要があると思います。 JS側を機能させることができれば、wasm仕様の変更を伴わないソリューションが望ましいと私たちは皆同意できると思います。 私は、あなたがそのセクションで説明している欠点と、それがJSのみのソリューションを受け入れられないものにしている理由を理解しようとしています。

wasm仕様の変更を伴わないソリューションが望ましいということには誰もが同意できると思います

番号！ ここで説明されているWeb以外のユースケースを参照してください。 wasm仕様にawaitがないと、各プラットフォームがアドホックに何かを実行することになります。JS環境はインポートを実行し、他の場所は「同期」とマークされた新しいAPIを作成します。一貫性が低くなると、wasmをWebから他の場所に移動するのが難しくなります。

しかし、はい、コアのwasmスペック部分をできるだけシンプルにする必要があります。 私はこれがそうだと思いますか？ ロジックの99％はJS側にあります（ただし、 @ RossTateは同意していないようで、まだそれを理解しようとしています-前回の回答で具体的な質問をして、物事を前進させたいと思っています）。

私の考えでは、コアwasm仕様の追加は、基本的にawaitをリストすることであり、「何かを待つ」ことを意味していると言えます。それだけです。

これらのセマンティクスをより正確に形式化できない限り、これにより、仕様にあいまいさや実装定義の動作が導入されます。 私たちはこれまでそれを避けてきました（SIMDの場合はかなりのコストがかかります）ので、これは間違いなく私がピン留めしてもらいたいものです。 これをより正式にするために提案自体を変更する必要はないと思いますが、「何かを待つ」は、仕様ですでに使用されている正確な用語で言い換える必要があります。

コアwasm仕様は、モジュール間の呼び出しについて何かを述べていますか？

インスタンスのインポートは、別のインスタンスのエクスポートでインスタンス化できます。 JS API（およびwasmの構成性原理）について私が理解していることから、このようなインポートの呼び出しは、概念的には、他のインスタンスがエクスポートした関数への直接呼び出しです。 同じことが、2つのインスタンス間で渡されるfuncrefのような関数値の（間接的な）呼び出しにも当てはまります。

推測して、いつかコアのwasm仕様に、wasmモジュールを作成してそのメソッドを呼び出すための新しい命令があるとしましょう。 その場合、ホストの外側で何かを待つことがポイントなので、トラップだけを待つと言うと思います。

対面会議で議論されたモジュール構成性の原則に基づいて、それは罠にかけられるべきではありません。 （構成された）モジュールインスタンスが1つだけあり、 awaitを実行したかのようになります。 つまり、 awaitは、最新のJSスタックフレームまでスタックをパックします。

これは、 fがいくつかのwasmインスタンスのエクスポートされた単項関数の値である場合、インスタンス化パラメータオブジェクト{"some" : {"import" : f}}が{"some" : {"import" : (x) => f(x)}}と意味的に異なることを意味することに注意してください。前者への呼び出しはwasmスタック内にとどまりますが、後者への呼び出しは、ほんのわずかですが、JSスタックに入ります。 これまでのところ、これらのインスタンス化パラメータオブジェクトは同等と見なされます。 コード移行/言語相互運用の観点から、なぜそれが役立つのかを説明することはできますが、現時点では余談になります。

そのアイデアは、提案で検討されている代替アプローチの2番目の段落と機能的に同じではありませんか？ そのようなことはできますが、なぜそれが良くないと思うのかを説明しました。

申し訳ありませんが、私はその代替案を別の意味で読んでいますが、私の混乱を説明する以外は、今は問題ではありません。 あなたが私の提案と同じ意味を持っているようです。その場合、賛否両論を議論する価値があります。

この提案がwasm側で非常に軽いという事実は、 await命令が、インポートされた関数の呼び出しと意味的に同一であるように見えるためです。 もちろん、あなたが指摘するように、慣習は重要です！ ただし、これが当てはまる機能はawaitだけではありません。 インポートされたほとんどの関数についても同じことが言えます。 awaitの場合、この機能を備えたモジュールにimport "control" "await" (func (param externref) (result externref))句を持たせ、この機能をサポートする環境で常にそのインポートをインスタンス化することで、規則に関する懸念に対処できると思います。適切なコールバックを使用します。

それは、あなたが探しているクロスプラットフォームの移植性を提供しながら、wasmを変更しないことによって大量の作業を節約するソリューションを提供するようです。 しかし、私はまだ提案のニュアンスを理解するために働いています、そして私はすでにこれまでのところたくさんを逃しました！

この提案がwasm側で非常に軽いという事実は、await命令が、インポートされた関数の呼び出しと意味的に同一であるように見えるためです。

FWIWこれはこの提案が最初に始まった場所ですが、そのような組み込み関数を使用することはVMにとってより不透明であり、一般的には推奨されません（ @binjiは元の議論でそれから離れることを提案したと思います）。

たとえば、あなたの議論に続いて、 memory.growやatomic.waitのようなものは、それに応じてimport "control" "memory_grow"またはimport "control" "atomic_wait"として実行することもできますが、そうではありません。実際の命令と同じレベルの相互運用および静的分析の機会（VM側とツール側の両方）を提供しないでください。

命令としてのmemory.growは、メモリがエクスポートされない場合でも有用であると主張できますが、 atomic.wait間違いなくコアの外部に実装できます。 実際、一時停止/再開が発生するレベルと、関数としてのawaitがatomic.waitよりもはるかに多くの魔法を必要とするという事実を除いて、 awaitと非常によく似ています。値が変更されるまで現在のスレッドをブロックするだけでなく、VMスタックと対話できる必要があるためです。

@tlively

「何かを待つ」は、仕様ですでに使用されている正確な用語で言い換える必要があります。

絶対そうです。 それが役立つなら、私は今、いくつかのより具体的なテキストを提案することができます：

When an await instruction is executed on a waitref, the host environment is requested to do some work. Typically there would be a natural meaning to what that work is based on what a waitref is on a specific host (in particular, waiting for some form of host event), but from the wasm module's point of view, the semantics of an await are similar to a call to an imported host function, that is: we don't know exactly what the host will do, but at least expect to give it certain types and receive certain results; after the instruction executes, global state (the store) may change; and an exception may be thrown.

The behavior of an await from the host's perspective may be very different, however, from a call to an imported host function, and might involve something like pausing and resuming the wasm module. It is for this reason that this instruction is defined. For the instruction to be usable on a particlar host, the host would need to define the proper behavior.

ところで、これを書いているときに私に来た別の比較は、ロードとストアの配置のヒントです。 Wasmはアラインされていないロードとストアをサポートしているため、ヒントは（ヒントが間違っていても）wasmモジュールで観察できるさまざまな動作につながることはありませんが、ホストの場合、特定のプラットフォームでの非常に異なる実装を提案します（より効率的かもしれません）。 つまり、仕様にあるように、これは内部的に観察可能な異なるセマンティクスのない異なる命令の例です： The alignment in load and store instructions does not affect the semantics 。

@RossTate

対面会議で議論されたモジュール構成性の原則に基づいて、それは罠にかけられるべきではありません。 （構成された）モジュールインスタンスが1つだけあり、待機して実行されたかのようになります。 つまり、awaitは、最新のJSスタックフレームまでスタックをパックします。

良さそうです、そして知っておくと良いです、ありがとう、私はその部分を逃しました。

これは私たちの誤解の一部を説明していると思います。 Module =>モジュール呼び出しは、以前の私のポイントであるwasm specatmに含まれていません。 しかし、あなたはそれらがどこにあるかもしれない将来のスペックを楽しみにしているように思えます。 いずれにせよ、これはここでは問題のようには見えません。構成性によって、その状況でawaitがどのように動作するかが正確に決まるためです（これは、以前に提案したことではありませんが、より理にかなっています）。

コアwasm仕様は、モジュール間の呼び出しについて何かを述べていますか？ 私はそれがそうしていることを覚えていません、そして今私はそれを見ません。 しかし、おそらく私は何かを逃しましたか？

はい、コアwasm仕様は、他のwasmモジュールからインポートされた関数とホスト関数を区別します（§4.2.6）。 関数呼び出しのセマンティクス（§4.4.7）は、関数を定義したモジュールに依存しません。特に、モジュール間の関数呼び出しは、現在、同じモジュールの関数呼び出しと同じように動作するように指定されています。

クロスモジュール呼び出しの下のawaitがトラップするように定義されている場合、ホストからの呼び出しによって作成された最後のダミーフレームの前にクロスモジュール呼び出しが存在するかどうかを調べるために、呼び出しスタックのトラバーサルを指定する必要があります。 （§4.5.5）。 これは、仕様の不幸な複雑さです。 しかし、クロスモジュール呼び出しトラップを使用すると構成性に違反することに同意します。したがって、スタック全体がホストからの最後の呼び出しにフリーズバックされるセマンティクスを優先します。 あなたが言うように、@ kripkenのように、 awaitをホスト関数の呼び出し（§4.4.7.3）と同様にすることを指定する最も簡単な方法です。 ただし、ホスト関数の呼び出しは完全に非決定的であるため、コア仕様の観点からの命令のより適切な名前はundefinedである可能性があります。 そしてこの時点で、コア仕様自体はundefined命令IMOの恩恵を受けないため、実際にはWebプラットフォーム（および移植性のためのWASI）によって常に提供される組み込みインポートを好み始めます。

意味的には、 waitrefとawaitを返すホスト環境への呼び出しは、単なるブロッキング呼び出しですよね？

これは、ブラウザのように非同期環境を持たず、通話のブロックをネイティブにサポートできる非Web埋め込みにどのような価値をもたらしますか？

@RReverser 、組み込み関数についてあなたが指摘していることがわかります。 解釈されていない関数と命令を介して操作を定義する必要がある場合の決定には、判断の呼び出しが含まれます。 この判断の1つの要素は、他の指示とどのように相互作用するかを考慮することだと思います。 memory.growは、他のメモリ命令の動作に影響を与えます。 スレッドの提案を熟読する機会はありませんでしたが、 atomic.waitが他の同期命令の動作に影響を与えるか、影響を受けると思います。 次に、これらの相互作用を形式化するために仕様を更新する必要があります。

しかし、 awaitだけでは、他の命令との相互作用はありません。 唯一の相互作用はホストとのやり取りです。そのため、この提案はインポートされたホスト関数を介して実行する必要があるというのが私の直感です。

atomic.waitとこの提案されたawaitの大きな違いは、モジュールをatomic.waitで再入力できないことだと思います。 エージェントは完全に停止されます。

@kripken ：

@rossbergの前回のプレゼンテーションからの私の理解は、彼は最初はそのルートをたどりたいと思っていましたが、その後、コルーチンアプローチを行うために方向を変えたということです。 「問題」というタイトルのスライドを参照してください。 そのスライドの後に、コルーチンについて説明します。これは、このスペースのもう1つのオプションです。 それで、多分あなたの質問はおそらく明確にすることができる@rossbergのためのものですか？

はい。したがって、コルーチン風の因数分解は、以前の再開可能な例外設計の一般化と考えることができます。 再開可能なイベント/例外の概念は同じですが、 try命令はより小さなプリミティブに分解されます。これにより、セマンティクスがより単純になり、コストモデルがより明確になります。 また、やや表現力豊かです。

これは、関連するすべてのコントロールの抽象化を表現できることを目的としており、非同期は動機付けのユースケースの1つです。 JS非同期と相互運用するために、JS APIはおそらく、Wasmモジュールがインポートしてthrowを一時停止できる事前定義されたawaitイベント（externrefとしてJSpromiseを実行）を提供できます。 もちろん、具体化する必要のある詳細はたくさんありますが、原則としてそれは可能であるはずです。

現在の提案に関しては、私はまだ頭を包み込もうとしています。 :)

特に、古いWasm関数でawaitを許可しているようですが、正しく読んでいますか？ もしそうなら、それは非同期関数でのみawaitを許可するJSとは大きく異なります。 これは非常に中心的な制約です。これにより、エンジンは単一の（非同期）関数の_local_変換によってawaitをコンパイルできるようになります。

その制約がなければ、エンジンは_global_プログラム変換を実行する必要があり（おそらくAsyncifyが実行するように）、すべての呼び出しがはるかに高価になる可能性があります（通常、一部の呼び出しが待機に達するかどうかはわかりません）。 または、同等に、エンジンは複数のスタックを作成してそれらを切り替えることができる必要があります！

さて、これはまさにコルーチン/エフェクトハンドラーのアイデアがWasmに導入しようとしている機能です。 しかし、明らかに、これはプラットフォームとその実行モデルへの非常に重要な追加であり、JSがその制御の抽象化（非同期やジェネレーターなど）を避けるために非常に注意を払っている複雑さです。

@rossberg

特に、古いWasm関数では待機できるようですが、正しく読んでいますか？ もしそうなら、それは非同期関数でのみ待機を許可するJSとは大きく異なります。

はい、ここのモデルは非常に異なります。 JS awaitは機能によるものですが、この提案はwasmインスタンス全体を待機します（JSとwasmの間、つまりJSとwasmの間の同期/非同期の不一致を解決することが目的であるため）。 また、JS awaitは手書きのコードを待機しますが、これはコンパイルされたコードの移植を可能にするためです。

そして、これは非常に中心的な制約です。これにより、エンジンは単一の（非同期）関数のローカル変換によってコンパイル待機できるようになります。 その制約がなければ、エンジンはグローバルプログラム変換を実行する必要があり（おそらくAsyncifyが実行するように）、すべての呼び出しがはるかに高価になる可能性があります（通常、一部の呼び出しが待機に達するかどうかはわかりません）。 または、同等に、エンジンは複数のスタックを作成してそれらを切り替えることができる必要があります！

間違いなく、グローバルなプログラム変換はここでは意図されていません！ それが明確でない場合は申し訳ありません。

提案で述べたように、スタック間の切り替えは1つの可能な実装オプションですが、コルーチンスタイルのスタック切り替えと同じではないことに注意してください。

• wasmインスタンス全体のみが一時停止できます。 これは、モジュール内のスタック切り替え用ではありません。 （特に、この提案がコアのwasm仕様に追加されず、完全にwasm JS側にある理由です。これまでのところ、これを好む人もいます。どちらの方法でも機能すると思います。）
• コルーチンはスタックを明示的に宣言しますが、awaitは宣言しません。
• awaitスタックは1回だけ再開でき、2回以上フォーク/リターンすることはありません（プロポーザルにそれがあるかどうかはわかりませんか？）。
• ここでは、パフォーマンスモデルが大きく異なります。 awaitは、すでに最小限のオーバーヘッドとレイテンシーを備えたJSのPromiseを待機します。 したがって、実際に一時停止するときに実装にオーバーヘッドがあれば問題ありません。コルーチンよりも気にしないでください。

これらの要因を考慮し、この提案の観察可能な動作は、wasmインスタンス全体が一時停止することであるため、それを実装するさまざまな方法があります。 たとえば、単一のwasmインスタンスを実行しているVMのWebから離れると、wasmを再開する時間になるまで、文字通りイベントループを実行できます。 Webでは、実装アプローチの1つは次のようになります。awaitが発生したら、現在の位置からwasmを呼び出した場所までwasmスタック全体をコピーします。 側にそれを保存します。 再開するには、コピーして戻し、そこから続行します。 これらには他のアプローチやバリエーションもあるかもしれません（おそらくコピーしないものもありますが、ここでも、コピーのオーバーヘッドを回避することは実際には重要ではありません！）。

長い投稿と提案テキスト自体からの繰り返しで申し訳ありませんが、これがあなたが言及したいくつかのポイントを明確にするのに役立つことを願っていますか？

ここでは、実装に関して議論することがたくさんあると思います。 これまでのところ、Lucetに関する@acfoltzerのコメントは心強いものです。

@kripkenの最新のコメントの一部の言い回しを明確にするために、一時停止するのはwasmインスタンス全体ではありません。 一時停止されるのは、ホストフレームからスタック上のwasmへの最新の呼び出しであり、代わりにホストフレームに対応するpromise（またはホストの適切なアナログ）が返されます。 関連する以前の説明については、ここを参照してください。

うーん、それがどのように違いを生むのかわかりません。 Wasmの奥深くで待つときは、少なくともホストエントリからそのポイントまでのすべてのコールスタックをキャプチャする必要があります。 また、その一時停止（つまり、スタックセグメント）を必要なだけ存続させながら、上から他の呼び出しを行ったり、さらに一時停止を作成したりできます。 そして、あなたはどこかから再開することができます（私は思いますか？）。 それには、区切られた継続のすべての実装機構が必要ではありませんか？ プロンプトは、個別の構成ではなく、Wasmエントリ時に設定されるだけです。

@rossberg

はい、一部のVMではそうなる可能性があります。 待機してコルーチンがまったく同じVM作業を必要とする場合は、少なくとも追加の作業は必要ありません。 その場合、await提案の利点は、便利なJS統合になります。

モジュールの再入力を許可しない場合は、プログラム全体を変換しなくても、便利なJS統合を実現できると思います。

モジュールの再入力を許可しない場合は、プログラム全体を変換しなくても、便利なJS統合を実現できると思います。

これはそれを行うためのより簡単な方法に聞こえますが、それはコールスタックで訪問されたすべてのモジュール（または最初のステップとして、すべてのWebAssemblyモジュール）をブロックする必要があります。

これはそれを行うためのより簡単な方法に聞こえますが、それはコールスタックで訪問されたすべてのモジュール（または最初のステップとして、すべてのWebAssemblyモジュール）をブロックする必要があります。

atomic.waitと同じように、正解です。

@taralx

モジュールの再入力を許可しない場合は、プログラム全体を変換しなくても、便利なJS統合を実現できると思います。

一方では、再入力が便利な場合があります。たとえば、ゲームエンジンがファイルをダウンロードし、その間UIを完全に一時停止したくない場合があります（Asyncifyでは現在それが可能です）。 しかし一方で、再入力は許可されない可能性がありますが、アプリケーションはそのために同じモジュールの複数のインスタンスを作成する可能性があります（すべて同じメモリ、可変グローバルなどをインポートしますか？）ので、再入力は呼び出しになります別のインスタンスに。 ツールチェーンでそれを機能させることができると思います（一度にアクティブになる再エントリの数には、インスタンスの数に等しい効果的な制限がありますが、これは問題ないようです）。

したがって、単純化がVMに役立つ場合は、検討する価値があります。

（ただし、前に説明したように、ここで説明しているオプションのいずれかを使用してプログラム全体を変換する必要はないと思います。必要なのは、Asyncifyが悪い状況にある場合のみで、ツールチェーンレベル。待ってください。 @ rossbergで説明した最悪の場合、コルーチンの提案が内部で行うことを実行できます。ただし、それよりも単純になると、アイデアは非常に興味深いものになる可能性があります。）

一方では、再入力が便利な場合があります。たとえば、ゲームエンジンがファイルをダウンロードし、その間UIを完全に一時停止したくない場合があります（Asyncifyでは現在それが可能です）。

ただし、これが適切な機能かどうかはわかりません。 ただし、これにより、アプリケーションに_予期しない同時実行性_が導入されるように思われます。 レンダリング中にアセットをロードするネイティブアプリケーションは、内部で2つのスレッドを使用し、各スレッドはWebWorker + SharedArrayBufferにマップされます。 アプリケーションがスレッドを使用する場合、WebWorkersからの同期Webプリミティブを使用することもできます（少なくとも場合によっては許可されているため）。 それ以外の場合は、Atomics.waitを使用して、メインスレッドの非同期操作をワーカーのブロック操作にマップすることが常に可能です（たとえば）。

一般的に、ユースケース全体がマルチスレッドによってまだ解決されていないのではないかと思います。 ワーカーでブロッキングプリミティブを使用することにより、スタック全体（JS / Wasm /ブラウザネイティブ）が保持されます。これは、はるかに単純で堅牢なようです。

ワーカーでブロッキングプリミティブを使用することにより、スタック全体（JS / Wasm /ブラウザネイティブ）が保持されます。これは、はるかに単純で堅牢なようです。

これは実際に私が実験したスタンドアロンのAsyncifyJSラッパーの別の代替実装ですが、コードサイズの問題は解決しますが、パフォーマンスのオーバーヘッドは、Wasm変換を使用する現在のAsyncifyよりもはるかに高くなりました。

@ alexp-sssup

ただし、これにより、アプリケーションに予期しない同時実行が発生するように思われます。

確かに、そうです-それは非常に注意深く行われる必要があり、物事を壊す可能性があります。 Asyncifyを使用した経験は、良いものと悪いものが混在しています（たとえば、有効なユースケース：ファイルがJSにダウンロードされ、JSがwasmを呼び出して、再開する前に、ファイルをコピーするスペースをmallocします）。 しかし、いずれにせよ、再入国はこの提案の重要な部分ではありません。

@RReverserが言ったことに加えて、スレッドに関する別の問題は、スレッドのサポートが普遍的ではなく、普遍的ではないということです。 しかし、待つことはどこにでもある可能性があります。

async / awaitが導入されている他の言語では、再入力が絶対に重要です。 （a）待っている間に他のイベントが発生する可能性があるというのは、そのような全体的なポイントです。 再入国はかなり重要だと私には思えます。

さらに、モジュールが外部関数を呼び出すときはいつでも、そのエクスポートのいずれかを介して再入力できると想定する必要があるというのは本当ではありません（上記の例では、待機していなくても、外部への呼び出しと外部関数はありません）関数は、mallocを呼び出すために無料です（しゃれは意図されていません）。

アプリケーションは、そのために同じモジュールの複数のインスタンスを作成する可能性があるため（すべて同じメモリ、可変グローバルなどをインポートしますか？）、再エントリは別のインスタンスへの呼び出しになります

モジュールの共有メモリのみ。 他のメモリは再インスタンス化する必要があります。これは、飛行中の変更で1つの操作が別の操作に踏み込まれないようにするために重要です。

これの非再入可能なバージョンは、誰かがそれで遊んで、それがどれほど有用であるかを見たい場合に備えて、スレッドサポートを備えた任意の埋め込みでポリフィル可能であることに注意してください。

これの非再入可能なバージョンは、誰かがそれで遊んで、それがどれほど有用であるかを見たい場合に備えて、スレッドサポートを備えた任意の埋め込みでポリフィル可能であることに注意してください。

上記のように、これはすでに試してみましたが、現在のソリューションよりもパフォーマンスがさらに悪く、普遍的にサポートされておらず、さらにWebAssembly.GlobalまたはWebAssembly.Tableを共有するのが非常に難しいため、破棄されました追加のハックなしでメインスレッドを使用するため、透明なポリフィルには適していません。

Wasmモジュールを書き換える現在のソリューションでは、これらの問題は発生しませんが、ファイルサイズにかなりのコストがかかります。

そのため、これらはどちらも大規模な実世界のアプリには適していません。そのため、ここで説明するような非同期統合のネイティブサポートを検討するようになります。

パフォーマンスの低下

ある種のベンチマークはありますか？

ええ、火曜日（または、おそらく水曜日）に仕事に戻ったときに共有できます。または、空の非同期JS関数を自分で呼び出すだけで簡単に作成できます。

ありがとう。 マイクロベンチマークを作成することはできますが、それほど有益ではありません。

そうそう、私たちは純粋にオーバーヘッドの比較に興味があったので、私のものもマイクロベンチマークです。

マイクロベンチマークの問題は、実際のアプリケーションで許容できるレイテンシがわからないことです。 さらに1ミリ秒かかる場合、たとえば、アプリケーションが1 / sの速度で待機操作のみを実行する場合、それは本当に問題になりますか？

アトミックベースのアプローチの速度に焦点を当てることは、気を散らすものかもしれないと思います。 前述のように、アトミックはどこでも機能しないし、機能しません（COOP / COEPのため）。また、メインスレッドがブロックできないため、アトミックアプローチを使用できるのはワーカーだけです。 これは素晴らしいアイデアですが、普遍的なソリューションには、Awaitのようなものが必要です。

私はそれを長期的な解決策として提案しているのではありません。 私は、それを使用するポリフィルを使用して、非再入可能なソリューションが人々に役立つかどうかを確認することを提案しています。

@taralxああ、わかりました、わかりました、ありがとう。

@taralx ：

モジュールの再入力を許可しない場合は、プログラム全体を変換しなくても、便利なJS統合を実現できると思います。

それは悪いことです。 これは、複数のモジュールをマージすると、それらの動作が損なわれる可能性があることを意味します。 それはモジュール性に対するアンチテーゼです。

一般的な設計原則として、動作動作はモジュールの境界に依存してはなりません（単純なスコープを除く）。 モジュールはWasmの単なるグループ化とスコープのメカニズムであり、プログラムの動作を変更せずに、ものを再グループ化する機能（モジュールのリンク/マージ/分割）を維持する必要があります。

@rossberg ：これは、前に提案したように、Wasmモジュールへのアクセスをブロックするものとして一般化できます。 しかし、それはおそらく制限が多すぎます。

それは悪いことです。 これは、複数のモジュールをマージすると、それらの動作が損なわれる可能性があることを意味します。 それはモジュール性に対するアンチテーゼです。

それがポリフィリングの議論での私のポイントでした- atomic.waitはモジュール性を壊さないので、これも壊すべきではありません。

@ taralx 、 atomic.waitは、特定のメモリ内の特定の場所を参照します。 awaitが使用をブロックするメモリと場所、およびそのメモリを共有するモジュールをどのように制御するか。

@rossbergこれが壊れると思うシナリオについて詳しく説明していただけますか？ 非再入可能バージョンがどのように機能するかについては、さまざまな考えがあると思います。

@ taralx 、2つのモジュールAとBをロードすることを検討してください。それぞれが、 A.fとB.gなどのエクスポート関数を提供します。 どちらも、呼び出されたときにawaitを実行する可能性があります。 2つのクライアントコードがそれぞれこれらの関数の1つに渡され、それらを個別に呼び出します。 それらは互いに干渉したりブロックしたりしません。 次に、誰かがコードについて何も変更せずに、AとBをCにマージまたはリファクタリングします。 突然、両方のクライアントコードが予期せずに相互にブロックし始める可能性があります。 隠された共有状態を介した距離での不気味なアクション。

それは理にかなっている。 ただし、再入力を許可すると、それを予期しないモジュールで同時実行のリスクが生じるため、どちらの方法でも、距離を置いた不気味なアクションになります。

しかし、モジュールはすでに再入力可能ですよね？ モジュールがインポートを呼び出すときはいつでも、外部コードはモジュールに再入力でき、戻る前にグローバル状態を変更する可能性があります。 提案された待機中の再入力が、インポートされた関数を呼び出すよりも不気味または同時であることがわかりません。 多分私は何かが欠けていますか？

（編集）

うーん、はい。 さて、インポートされた関数はモジュールに再び入ることができます。 私は明らかにこれについてもっと深く考える必要があります。

コードが実行されていて、関数を呼び出す場合、2つの可能性があります。関数がランダムなものを呼び出さないこと、または関数がランダムなものを呼び出す可能性があることを知っていることです。 後者の場合、再入可能は常に可能です。 同じルールがawaitにも適用されます。

（上記の私のコメントを編集しました）

これまでの議論に感謝します！

要約すると、ここには一般的な関心があるように聞こえますが、これをJS側で100％にするか、99％にするかなど、大きな未解決の質問があります。前者は、一部の人々が抱える大きな懸念を取り除くように思えます。 Webの場合は問題ないので、おそらく問題ありません。 もう1つの大きな未解決の質問は、詳細情報が必要なVMでこれを実行することがどれほど実現可能かということです。

2週間後の次のCGミーティングの議題項目を提案して、この提案について話し合い、ステージ1で検討します。つまり、レポを開き、別の問題で未解決の質問について詳しく話し合うことを意味します。 （これは正しいプロセスだと思いますが、間違っている場合は訂正してください。）

参考までに
同様の方法でフルスタックスイッチングの提案をまとめます
時間枠。 それはあなたの特別な場合の変種を無意味にするかもしれないと私は感じます-
どう思いますか？
フランシス

2020年5月28日木曜日午後3時51分に[email protected]は次のように書いています。

これまでの議論に感謝します！

要約すると、ここには一般的な関心があるように思えますが、
これをJS側で100％にするべきか、それとも単に
99％-前者は一部の人々の主要な心配を取り除くように聞こえます
持っていて、それはWebの場合は問題ないので、おそらく問題ありません。
もう1つの大きな未解決の質問は、これがVMで実行できるかどうかです。
についての詳細が必要です。

2週間後の次のCGミーティングの議事項目を提案して話し合います
この提案をステージ1で検討します。これは、レポを開くことを意味します。
未解決の質問については、別の問題で詳しく説明しています。
（これは正しいプロセスだと思いますが、間違っている場合は訂正してください。）

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WebAssembly/design/issues/1345#issuecomment-635649331 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAQAXUCLZ4CJVQYEUBK23BLRT3TFLANCNFSM4NEJW2PQ
。

>>

フランシス・マッケイブ
SWE

@fgmccabe

確かにそれについて話し合うべきです。

ただし、一般的に、提案がJS側に焦点を当てていない限り、これは1つの意味をなさないだろうと思います（JS側では99％〜100％です）。

実装の詳細についての議論が終わったので、私は以前に表明したより高いレベルの懸念を再提起したいと思いますが、一度に1つの議論をするためにやめました。

プログラムは多くのコンポーネントで構成されています。 ソフトウェアエンジニアリングの観点からは、コンポーネントをパーツに分割したり、コンポーネントをマージしたりしても、プログラムの動作が大幅に変更されないことが重要です。 これは、前回の対面式CG会議で議論されたモジュール構成の原則の背後にある理由であり、多くの言語の設計に暗黙のうちに含まれています。

Webプログラムの場合、WebAssemblyを使用すると、これらのさまざまなコンポーネントがさまざまな言語（JSまたはwasm）で記述されることもあります。 実際、多くのコンポーネントはどちらの言語でも同様に記述できます。 これらを「アンビバレント」コンポーネントと呼びます。 現在、ほとんどのアンビバレントなコンポーネントはJSで記述されていますが、ますます多くのコンポーネントがwasmに書き換えられることを期待しています。 この「コードの移行」を容易にするために、この方法でコンポーネントを書き直しても、コンポーネントが環境と相互作用する方法が変わらないようにする必要があります。 おもちゃの例として、特定の「適用」プログラムコンポーネント(f, x) => f(x)がJSで記述されているか、wasmで記述されているかは、プログラム全体の動作に影響を与えないはずです。 これはコード移行の原則です。

残念ながら、この提案のすべての変形は、モジュール構成プログラムまたはコード移行の原則のいずれかに違反しているようです。 awaitが、現在のwasmモジュールが最後に入力された場所までのスタックをキャプチャすると、前者に違反します。これは、モジュールが分割または結合されると、この境界が変化するためです。 後者は、 awaitがwasmが最後に入力された場所までのスタックをキャプチャするときに違反します。これは、コードがJSからwasmに移行されると、この境界が変化するためです（つまり、 (f, x) => f(x)からJS to wasmは、プログラム全体の動作を大幅に変える可能性があります）。

これらの違反は、この提案の設計上の選択が不十分なためではないと思います。 むしろ、問題は、この提案が間接的にJSをこれ以上強力にすることを回避しようとしていることであり、その目標は、これらの原則に違反する人工的な境界を課すことを強制していることです。 私はその目標を完全に理解していますが、この問題はますます発生するのではないかと思います。これらの原則を尊重する方法でWebAssemblyに機能を追加するには、JSが埋め込み言語であるため、間接的にJSに機能を追加する必要があります。 私の好みは、その問題に正面から取り組むことです（これを解決する方法が本当にわかりません）。 そうでない場合、私の2番目の好みは、JS APIでのみこの変更を行うことです。これは、wasmが解釈しない命令をWebAssemblyに追加するのではなく、ここで制限要因となるのはJSだからです。

これらの違反は、この提案の設計上の選択が不十分なためではないと思います。 むしろ、問題は、この提案が間接的にJSをこれ以上強力にすることを回避しようとしていることであるように思われます

それは重要ですが、それがここでの設計の主な理由ではありません。

この設計の主な理由は、構成の原則がwasmにとって理にかなっていることに完全に同意しますが、Webでの根本的な問題は、実際にはJSとwasmが実際には同等ではないということです。 非同期の手書きJSと、同期の移植されたwasmがあります。 言い換えれば、それらの間の境界は、実際に私たちが対処しようとしている正確な問題です。 全体として、構成の原則をwasmとJSに適用する必要があることに同意するかどうかはわかりません（ただし、おそらくそれは興味深い議論になる可能性があります）。

ここでもっと多くの議論をしたいと思っていましたが、時間を節約するために、これまでここに参加した人はほとんどいないため、VMの実装者に直接連絡しました。 ここでの議論と一緒に彼らのフィードバックを考えると、悲しいことに、私たちはこの提案を一時停止する必要があると思います。

Awaitの動作は、一般的なコルーチンやスタックスイッチングよりもはるかに単純ですが、私が話したVMの人々は、最終的にVMが動作するのはおそらく両方で似ているという@rossbergに同意します。 そして、少なくとも一部のVMの人々は、コルーチンやスタックスイッチングをとにかく取得し、それを使用してawaitのユースケースをサポートできると信じています。 これは、（この提案とは異なり）wasmへの呼び出しごとに新しいコルーチン/スタックを作成することを意味しますが、少なくとも一部のVMの人々は、それを十分に高速化できると考えています。

VMの人々からの関心の欠如に加えて、上記のように、 @ fgmccabeと@RossTateからのこの提案に対していくつかの強い反対がありました。 私たちはいくつかの点で意見が一致しませんが、私はそれらの観点とそれらを説明するために費やされた時間に感謝します。

結論として、全体として、ここで前進しようとするのは皆の時間の無駄だと感じています。 しかし、議論に参加したすべての人に感謝します！ そして、少なくともこれがコルーチン/スタック切り替えの優先順位付けの動機になることを願っています。

この提案のJS部分は、基本的にPromiseの統合に便利なJSシュガーであるため、将来的に関連する可能性があることに注意してください。 スタックの切り替えまたはコルーチンを待って、これがその上で機能するかどうかを確認する必要があります。 しかし、そのために問題を開いたままにしておく価値はないと思うので、閉じます。