イベントループ
(メッセージ ループ から転送)
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2023/06/06 17:09 UTC 版)
イベントループ (event loop)、メッセージディスパッチャ (message dispatcher)、メッセージループ (message loop)、メッセージポンプ (message pump)、ランループ (run loop) とは、プログラム内でイベントやメッセージを待ち受け、それらをディスパッチ(配送)する構成要素である。内部または外部の「イベントプロバイダー」(通常、イベントが到着するまで要求をブロックする)に要求することで動作し、次いで適当なイベントハンドラー (event handler) を呼び出す(イベントのディスパッチ)。イベントプロバイダーが後述のファイルインタフェースに従う場合、イベントループは reactor と連携する形で使われることがあり、select()
または poll()
を使ってファイルインタフェースにアクセスする。イベントループはほぼ常にメッセージの発信元とは非同期に動作する。
注釈
出典
- ^ D. J. Bernstein. “The self-pipe trick”. 2013年2月5日閲覧。
- ^ BUGS,
pselect(2)
: synchronous I/O multiplexing – Linux System Calls Manual (en) - ^ WinMain function (winbase.h) | Microsoft Docs
- ^ Window Procedures - Windows applications | Microsoft Docs
- ^ GetMessageW function (winuser.h) | Microsoft Docs
- ^ PeekMessageW function (winuser.h) | Microsoft Docs
- ^ GetMessage() function with message priority list.[要説明]
- ^ Idle Loop Processing | Microsoft Docs
- ^ Sharing Message Loops Between Win32 and WPF | Microsoft Docs
- ^ Windows Forms and WPF interop input architecture | Microsoft Docs
- ^ X11R5、X11R6、Xtでの対処法は Chapter: 26 Signal Handling
- ^ The Main Event Loop - Customizing the main loop iteration Gnome Dev Center
- ^ Message | Android Developers
- ^ MessageQueue | Android Developers
- ^ Looper | Android Developers
- ^ Handler | Android Developers
- ^ core/java/android/os/Looper.java - platform/frameworks/base - Git at Google
- ^ Looper | Android NDK | Android Developers
- ^ サンプル: native-activity | Android NDK | Android Developers
- 1 イベントループとは
- 2 イベントループの概要
- 3 脚注
メッセージループ
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/09/01 06:22 UTC 版)
全ての対応プラットフォームがメッセージループを持つ。具体的には、全てのプラットフォームで、Win32のGetMessage(), PeekMessage(), DispatchMessage()相当の関数が存在しており、それを組み合わせることにより独自のメッセージループをどこでも書くことができる。たとえば、キーイベントハンドラやメニューハンドラの中で、独自のメッセージループを書けば、条件が満たされるまでその場で半永久的に停止することも可能である。このことにより、MS WindowsのWin32と似た流儀のプログラムが可能となるため、Win32やMFCから移植し易い。技術的側面では、ブラウザ上のJSでは、本来はメッセージループを自分では記述できないため、このようなことはWebAssemblyを用いても純粋なC/C++やRust言語をコンパイルしただけではできない。しかし、SuperCの場合、コンパイラが関数を自動的に特殊変形することができるようになっているため、WebAssembly出力においても、SuperCのソースコードレベルでは簡単に記述できる。ブラウザ上のWebAssembly版においてキーイベントハンドラやメニューハンドラの中で独自のメッセージループを書いた場合、内部的には単純な無限ループではなく、プラットフォームの(見えない)イベントキューに自動的に一旦戻り、生のイベントが発生すると、関数が巻き戻されて、条件をチェックする、ということが条件が満たされるまで繰り返される。このときに用いられている技術は、大域ジャンプを強化したようなものである。大域ジャンプでは、一方向にしかジャンプできないが、SuperCでは、スタックの情報を上手く記録することにより、双方向にジャンプできるようになっている。なお、通常のプラットフォームでは、関数の戻り値を記録するスタックとローカルオート変数を記録するスタックが共通であるため、その共通スタックだけを記録すれば比較的簡単にこの機能が実現できる。しかし、LLVMでは、関数の戻りアドレスを記録するスタックとローカルオート変数を記録するスタックが別であるし、スタックの内容を単純なバイト列としてコピーしたり、スタックポインタをLLVMアセンブラレベルで独自に再設定するのも禁止に近いため、単純には行かない。SuperCでは、生のイベントキューに戻る際には、LLVMのret文を複数回連続して使い、逆に関数の場所に戻る時には、LLVMのcall文を関数の呼び出し階層数と同じ回数だけ使っている。その際、関数の仮引数も必要あらば設定し直している。もし、この仕組みを使わずに単純なループで待機した場合、CPUの消費は100%に近くなり電池の消耗や発熱量は激しくなるが、NWSTKの独自メッセージループで待機する場合には、この仕組みを用いているため、CPUパワーの消費は0に近く、モバイルデバイスにおける電池の消耗は最小限にできる。
※この「メッセージループ」の解説は、「NWSTK」の解説の一部です。
「メッセージループ」を含む「NWSTK」の記事については、「NWSTK」の概要を参照ください。
- メッセージ ループのページへのリンク