>>9
正しくは、「WebAPI」ではなく、ブラウザ上の JS で使える EventLoop などの
仕様のこと。

1. JS では、Win32 の GetMessage() や PeekMessage() のような、
　Event Queue の現在の中身を直接を調べるような関数が存在しないらしい事。
2. WebWorker で WorkerThread を作っても、結局、DOMには
　アクセスできない事。
3. さらに、WorkerThrad では、イベントを受け取ることも出来ない事。
4. Win32 の GetAsyncKeystate() のような、イベントによらないでキーの
　 On/Off 状態を取得する方法が無いこと。
5. 以上の事は、OpenFileDialog() や getch()、pause() 文の模倣をそのままでは
　原理的に不可能にする可能性がとても高い。

[回避策]
a. C/C++ のステートメントの実行を一行実行するたびにイベントループに戻る
　ような「インタプリタ的な」実行法を採用する。これは、「Emterpreter」
　(「Emscripten」と似ているが違うので注意）なるやり方が相当。
b. 関数のコンパイルの仕方を大幅に変更する方法。これが、ASYNCIFY=1
　に相当すると思われる。具体的には、関数で「待つ」必要がある場合には、
　イベントループに戻る。このことは、結論的には、JSやwasmの色々な機能不足を
　一挙に解決できる。イベントループに戻ることで、キーやマウスのイベントを
　受け取ることも出来るようになるし、タイマーイベントが発生するまでCPUを
　hlt 状態にすることも出来るようになる。この事は実は似ているが、よく考えると
　別の事柄でもあったりするので、説明が難しいが、とにかく、一挙に色々な
　事を解決できるようになる。GetAsyncKeyState() 相当の関数が無いことと
　Atomics の wait(), wake(), notify() が、限られたブラウザでしか実装されて無い事
　の問題も解決する。誤解を招かずに説明するには話が長くなるのが・・・。