Design: asynchron / Unterstützung versprechen

Jegliche Unterstützung von JS-Versprechen müsste Teil des JS-Hostbindungsvorschlags sein .

Aber ich fürchte, es kann unmöglich so funktionieren, wie Ihr Beispiel vermuten lässt, da dies erfordert, dass C selbst die asynchrone Ausführung und Aussetzung versteht, was nicht der Fall ist. Außerdem ist in Ihrem Beispiel nichts asynchron, es erstellt nur ein Versprechen, sodass der entsprechende Code nicht einmal in JS selbst anhalten würde, sondern nur eine Zeichenfolge wie "[object Promise][object Promise]" .

Außerdem ist in Ihrem Beispiel nichts asynchron

Nun, der Wert ist erst verfügbar, wenn die Eventloop das Promise verarbeitet hat.
Die Idee ist, die Ausführung der Webassembly-Engine auszusetzen, bis der Wert verfügbar ist.
Das mitgelieferte Beispiel ist natürlich sehr trivial. Ein konkreteres Beispiel könnte eine DB-Abfrage über das Netzwerk sein: getAgeOf: (name) => db.find({name}).then(x=>x.age)

C selbst, um die asynchrone Ausführung und Aussetzung zu verstehen, was nicht der Fall ist

Das ist falsch. Es gibt verschiedene Coroutine- Implementierungen für C.
Darüber hinaus unterstützt LLVM-5.0 und höher Coroutinen und Async/Await.

https://llvm.org/docs/Coroutines.html

Und als Ergänzung zu C++17 gibt es die seit clang-5.0 implementierte Coroutine-ts .
Es gibt bereits einige experimentelle Bibliotheken, die es verwenden:
https://github.com/lewissbaker/cppcoro#generator

Implementierungen von Coroutinen in C interagieren nicht auf magische Weise mit der Ereignisschleife von JavaScript. Außerdem verlassen sie sich normalerweise auf implementierungsspezifisches Verhalten. Um so etwas wie Coroutinen oder Async zuverlässig und portabel zu implementieren, benötigen Sie eine Form von begrenzten Fortsetzungen in der Sprache. Das nächste, was C zu bieten hat, ist longjmp, was nicht ausreicht und derzeit nicht in Wasm selbst implementiert werden kann (mit Emscripten ist longjmp in JS mit JS-Ausnahmen implementiert). Wasm kann derzeit keine Suspendierung aussprechen, obwohl geplant ist, irgendwann etwas in diese Richtung hinzuzufügen. C++-Coroutinen sind noch nicht Standard und können von Emscripten AFAICT nicht verarbeitet werden.

Ich sehe, woher du kommst.
Ich glaube, ich habe meine Idee nicht gut genug ausgedrückt.
Ich schlage nicht vor, Coroutinen oder Versprechen in C/C++ zu unterstützen oder dies im Wasm-Bytecode zu erkennen.

Aber ich fürchte, es kann unmöglich so funktionieren, wie Ihr Beispiel vermuten lässt, da dies erfordern würde, dass C selbst die asynchrone Ausführung und Aussetzung versteht, was nicht der Fall ist

Warum ist es Ihrer Meinung nach erforderlich, dass C die asynchrone Ausführung versteht?

Was ist die technische Schwierigkeit, die Wasm-Ausführungs-Engine anzuhalten, bis das Versprechen gelöst ist?

Ich verstehe, dass wasm im Voraus auf x86 kompiliert werden soll, aber das bedeutet nicht, dass Sie keine Kontrolle über den Ausführungsfluss haben.
Eine übliche Methode zum Stoppen der Ausführung besteht darin, Hardware-Interrupts und Systemaufrufe wie ptrace zu verwenden; So funktionieren Debugger. Wir wissen genau, welche Funktionen importiert werden und könnten die entsprechenden (x86) Opcodes einschleusen, um dies zu erreichen. Obwohl dies die Ausführung dieser Funktionen verlangsamen wird, wäre es egal, da wir in diesen Fällen sowieso darauf warten, dass das Versprechen gelöst wird.
So haben wir Suspend/Debug/Resume in unserem LLVM-basierten C++JIT/AoT implementiert.

Ich denke, dieses Problem sollte im Host-Bindungs-Repository abgelegt werden ...

Ich glaube, Sie missverstehen das Rechenmodell des Webs. JavaScript ist nicht multithreaded, daher würde das Aussetzen einer Berechnung die Engine und sogar den gesamten Renderer, der sie hostet, anhalten. Die Seite würde einfrieren und kein anderer Code könnte ausgeführt werden (außer separaten Workern). Sie müssten eine Möglichkeit haben, Fortsetzungen zu verifizieren und später wiederherzustellen, um die Federung zum Fliegen zu bringen, was Motoren derzeit nicht können.

verwandt: https://github.com/WebAssembly/design/issues/720

Ich glaube, Sie missverstehen das Rechenmodell des Webs. JavaScript ist nicht multithreaded, daher würde das Aussetzen einer Berechnung die Engine und sogar den gesamten Renderer, der sie hostet, anhalten. Die Seite würde einfrieren und kein anderer Code könnte ausgeführt werden (außer separaten Workern). Sie müssten eine Möglichkeit haben, Fortsetzungen zu verifizieren und später wiederherzustellen, um die Federung zum Fliegen zu bringen, was Motoren derzeit nicht können.

Genau, wasm sollte innerhalb von Workern ausgeführt werden, da sie beide für Rechenaufgaben erstellt wurden, anstatt sich mit der Benutzeroberfläche zu befassen.