ITedite

select、poll、epoll、libeventの関係

※この記事は調査中なので嘘が含まれている可能性があります。
select、poll、epollはどれもイベントハンドラ。
libeventはそれら意識せずに使うためのラッパー。
具体的に何をやっているかというと
 1. 一つもしくは複数のディスクリプタを監視
 2. 監視ループ突入(必須というわけじゃないけど、普通サーバは常時接続を監視するから無限ループにする)
 3. 監視期間設定
 4. 呼び出されると、監視期間の間、ディスクリプタの準備が整っているかチェック
 5. 準備が整ったディスクリプタが見つかったら通知
※5. で、準備が整った時点で通知されるのか、監視期間のタイムアウトまで待たされるのかは未検証。
端的にいうと、入出力のあったディスクリプタをイベントとして
アプリケーションに通知する役割を果たしている。
じゃー、違いはなんなのさっていう話になると思うが、
上記の4.「呼び出されると、監視期間の間、ディスクリプタの準備が整っているかチェック」のチェックの仕方が
イベントハンドラによって違う。
以下に簡単にまとめる。

監視できるディスクリプタの数 準備が整ったディスクリプタの探し方 ディスクリプタが見つかった後の処理 負荷
select 1024(カーネルいじれば変えられる) 全ディスクリプタをサーチ。 準備が整っているディスクリプタに対して個別処理 重い
poll ユーザが指定できる 全ディスクリプタをサーチ。 準備が整っているディスクリプタに対して個別処理 重い
epoll ユーザが指定できる kernel様が勝手にReady状態のディスクリプタを通知してくれる(サーチ不要) 準備が整っているディスクリプタに対して個別処理 軽い
libevent イベントハンドラ依存? イベントハンドラの実装に応じて、Ready状態のディスクリプタ検出 引数として渡しているコールバック関数の実行 イベントハンドラ依存

参考:http://alpha.mixi.co.jp/blog/?p=76
※懸念
select、pollはイベントハンドラと呼んでいいのか微妙