イベントループ (event loop)、メッセージディスパッチャ (message dispather)、メッセージループ (message loop)、メッセージポンプ (message pump)、ランループ (run loop) とは、プログラム内でイベントやメッセージを待ちうけ、それらをディスパッチする構成要素である。内部または外部の「イベントプロバイダー」（通常、イベントが到着するまで要求をブロックする）に要求することで作動し、次いで適当なを呼び出す（イベントのディスパッチ）。イベントプロバイダがファイルインタフェースに従う場合、イベントループは と連携する形で使われることがあり、codice_1 または codice_2 を使ってファイルインタフェースにアクセスする。イベントループはほぼ常にメッセージの発信元とは非同期に動作する。イベントループはプログラムの中心的制御構造となっていることが多い。そのためそれをメインループ (main loop) またはメインイベントループ (main event loop) とも呼ぶ。そのようなプログラムではイベントループが最上位の制御構造となっており、そのため「メイン」と名づけられている。メッセージポンプという呼称は、プログラムのメッセージキュー（通常OSが割り当て、OSが所有する）からメッセージを汲み上げ、そのプログラム内で処理することに由来する。厳密には、イベントループはプロセス間通信の実装法の1つである。実のところメッセージ処理は多くのシステムに存在し、例えばMachのカーネルレベルのコンポーネントにもある。イベントループはメッセージを使用するシステムの実装技法の1つである。この手法は以下のような他の手法とは対照的である:GUIインタフェースが主流となったため、多くのアプリケーションがメインループを持つようになった。codice_3 というルーチンは一般にOSが提供するもので、メッセージが到着するまでブロックされる。したがってこのループが動作するのは処理すべきものが存在する場合だけである。UNIXでは「あらゆるものはファイルである」というパラダイムにより、ファイルベースのイベントループが自然に生まれた。ファイルの読み書きだけなく、プロセス間通信、ネットワーク通信、デバイス制御が全てファイルI/Oで行われ、対象はファイル記述子で指定される。select および poll システムコールを使えば、複数のファイル記述子の状態変化を同時に監視でき、読み込むべきデータが到着したことを検知できる。例として、継続的に更新されるファイルから読み込んでその内容を X Window System に表示するプログラムを示す。クライアントとはソケットを通じて通信する。UNIXでファイルインタフェースに従わない数少ない例として、非同期イベント（シグナル）がある。シグナルはシグナルハンドラで受信する。シグナルハンドラは小さな制限されたコードであり、それが動作中はプログラム本体の処理はサスペンドされる。codice_1 でブロック中にシグナルを受信して処理した場合、select はEINTRというエラーコードを伴って早期に戻る。プログラムがCPUを使用している間にシグナルを受信すると、シグナルハンドラを実行する間は本体の実行がサスペンドされる。したがってシグナルを考慮するには、シグナルハンドラで大域変数のフラグをセットし、イベントループの codice_1 呼び出しの直前と直後でそのフラグをチェックすればよい。フラグがセットされていたら、ファイル記述子でのイベントと同様にシグナルを処理する。しかしながら、この技法では競合状態が生じる。フラグのチェックとcodice_1呼び出しの間にシグナルが到着した場合、codice_1 が他の理由で戻るまでシグナルを処理できない。この問題を解決するため、POSIXでは pselect システムコールを提供している。これは select に似ているが codice_8 という引数が追加されており、シグナルのマスクを設定できる。これを使えば、普段はシグナルをマスクしておき、select を呼び出している間だけマスクを解除することができる。すると、シグナルは select がイベントを待ち受けている間だけ受信されることになる。ただし、codice_9 が利用可能となったのは比較的最近のことで、Linuxカーネルの 2.6.16 より以前の版では codice_9 システムコールは実装されておらず、glibcで競合状態の問題をはらんだ実装がなされていた。より汎用的な代替技法として、非同期イベントを "self-pipe trick" と呼ばれる技法でファイルベースのイベントに変換してやる技法がある。これはシグナルハンドラでパイプに1バイトを書き込み、そのパイプのもう一方の端を主プログラムが select で監視するという技法である。Linuxカーネル 2.6.22 では、signalfd() という新システムコールが追加された。これはシグナル受信用の特別なファイル記述子を生成する。Microsoft Windows にてユーザーとやりとりするプロセスを動作させる場合、イベントに応答するためのメッセージループが必須である。Windows ではイベントとメッセージは同等視される。イベントとしては、ユーザーとのやりとり、ネットワークのトラフィック、システム処理、タイマー、プロセス間通信などがある。対話型でないI/Oのみのイベントについては、がある。I/O完了ポートのループはメッセージループとは別に動作し、メッセージループと相互作用することがない。大抵のWin32アプリケーションの「心臓部」は WinMain 関数であり、ループ内で GetMessage() を呼び出す。GetMessage はメッセージまたは「イベント」を受信するまでブロックする。何らかの選択的処理の後 DispatchMessage() を呼び出し、対応するハンドラ () にメッセージをディスパッチする。専用の WindowProc のないメッセージは DefWindowProc というデフォルトのハンドラにディスパッチする。DispatchMessage はメッセージのHWNDハンドル（RegisterClassで登録）に対応するWindowProcを呼び出す。より最近の Windows では、システムや周辺機器が受信した順序でメッセージループにメッセージが到達することを保証している。これはマルチスレッドアプリケーションの設計で必須となる。ただし、一部のメッセージには異なる規則が適用され、常に最後に受信されるメッセージや文書化された特別な優先順位で受信されるメッセージがある。Xlibを直接使用するXアプリケーションは、codice_11ファミリの関数を中心に構築される。codice_11はイベントキューにイベントが到着するまでブロックし、イベントを受け取ると即座にアプリケーションが適切にそれを処理する。Xlibのイベントループが扱うのはウィンドウシステムのイベントのみである。他のファイルやデバイスについても待ち受ける必要がある場合は codice_13 などのプリミティブからイベントループを自前で構築する必要があるが、一般にマルチスレッドを採用することが多い。Xlibを直接使用するプログラムは少ない。より一般的にはXlib上に構築されたGUIツールキットを使用する。例えば、X Toolkit Intrinsics (Xt) 上のツールキットでは codice_14 と codice_15 を使用する。なお、シグナル受信時の状態が不定であるため、シグナルハンドラからXlib関数を呼び出すのは危険である。GLibのイベントループはGTK+向けに作られたが、今ではD-BusなどのGUI以外のアプリケーションでも使われている。ファイル記述子群で監視したいリソースを指定する。シグナルを受信するかタイムアウトすると、ブロック状態から復帰する。GLibはファイル記述子と子プロセス終了のイベントを組み込みでサポートしているが、prepare-check-dispatch モデルの対象として任意のイベントを加えることが可能である。GLibのイベントループを使っているアプリケーションライブラリとしては、GStreamerやGnomeVFSの非同期IOメソッド群があるが、最大のクライアントライブラリはGTK+である。ウィンドウシステムからのイベント（Xの場合、Xのソケットからの読み込み）はGTK+イベントに変換され、アプリケーションのウィジェットオブジェクト上のGLibシグナルとして発せられる。OS X では、スレッド毎に1つの CFRunLoop があり、それに任意個のソース（イベント源）とオブザーバ（ハンドラ）を対応させることができる。そのループがメッセージのキューイングとディスパッチを行い、それを通してソースとオブザーバがやりとりする。Cocoaでは CFRunLoop が NSRunLoop に抽象化されており、任意のメッセージをキューイングして任意のオブジェクトにディスパッチできる。

出典:wikipedia