liveventの意義

最近注目度ナンバーワンのmemcachedであるが、そのソースコードはシンプルでありビルドも非常に簡単なのだが、リンクするべきライブラリがただ一つだけ存在する。それがlibeventである。
http://monkey.org/~provos/libevent/

libeventとはその名の通りイベント通知ライブラリである。と言っただけではなんのこっちゃ？！と思われることだろう。別の言い方をすると非同期I/Oライブラリてな感じだろうか。

※オトコたるもの滅多なことでそもそも論をしてはいけないが、非同期I/Oについて語らねば先に進まないので致し方なしとする。

そもそもディスクへの読み書きなどのI/O処理は他の電子部品とは違い、もの凄く遅い。電子部品はその名の通り電子の速さで処理が進むが、ディスク装置などには駆動部があったりするのでI/O処理はCPUなどの電子部品と比べると極めて遅いものになる。I/Oが完了するまで処理を停止しておくのも一つの方法であるが、そうすると処理効率が極端に落ちてしまう。そこで、I/Oの処理をバックグラウンドでやらせておいて処理が完了した時点で通知をもらえばいいじゃん！という発想に至ることになる。これがまさに非同期I/Oであり、使えば特にCPUの利用効率が格段に向上する。ちなみにI/Oが完了するまで処理を停止するやり方は同期I/Oという。そのまんまやんけ・・・。

ここで問題がある。実は近代的なUNIX系システムにおいて、非同期I/Oの実装方法にはかなりばらつきがあるのだ。なぜばらつきがあるかというと、そもそもPOSIXで定義されているpollだのselectだのという古めかしいインターフェイスは効率が悪い。そこで仕方なく各種UNIX系システムでは我こそが一番！的なノリ（ホントか？）で効率的な非同期I/Oインターフェイスを独自に実装している。

• Linuxではepoll()
• FreeBSDではkqueue
• Solarisでは/dev/poll

という具合だ。しかしそのようなばらつきがあると、プログラムの移植性が極度に低下してしまう。例えオープンソースであってでも！！！である。非同期I/Oは近代的なプログラムにとってはほぼ必須の機能であり、そのせいで移植性がよくないとなると一大事だ！！！

そこで登場したのがlibeventである。libeventでは各種UNIX系システムで定義された非同期I/Oに対して統一的なインターフェイス（ラッパー）を用意して、どのシステムにおいても同じコードで非同期I/Oを処理することを可能にしている。なんと素晴らしいことであろうか？！

しかしながら、そもそもPOSIXの非同期I/Oの効率がよろしくないのが問題なのであり、今後POSIXが改訂されて非同期I/Oが改善された暁には、libeventは用無しまたはお蔵入りまたは過去の遺産または死後の世界になる可能性もある。個人的にはぶっちゃけLinuxのepollがPOSIX標準になればいいんじゃないかと思う。そうすればPOSIX対応を謳うシステムではepollを実装することになるので万事解決！！libeventはさようなら！！

しかしながら現状はそうなってないのであり、唯一の選択肢はlibeventだけであるといえる。そもそもlibeventは優れたソフトウェアであり、そんなに嫌う必要もない。その証拠に、MySQLの派生プロジェクトであるDrizzleでもlibeventが採用されている。libeventはやはり便利なのである。ブラボー！

先日、同じ会社の開発者たちと話をしていたのだが、libeventは優れたソフトウェアであるが余計なモノもついていて、社内にはそれを嫌う人間もいるという。確かに言われてみれば、何故か以下のような機能がついているのがなんとも気になる。

• 非同期DNS検索
• イベント駆動型HTTPサーバ
• RPCフレームワーク

なんでやねん！と突っ込みたいところだが、libevent開発者の茶目っ気なのだろうか...。使わなければいいだけではあるが、それでもlibeventのフットプリントが大きくなるわけであるし、このように本来の機能とは関連性のないものはまさに蛇足であると言えよう。

果たしてlibeventの命運や如何に？！！