※この記事は調査中なので嘘が含まれている可能性があります。
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はイベントハンドラと呼んでいいのか微妙