/var/log/hdk.log の 4/22
に,
Linux の ulimit -n って root で使うと上限 1024 をこえられるね。
でもマクロ FD_SETSIZE が 1024 だから、まずくない?
特に select() するようなプログラムが。
FD_SET でバッファオーバフローする予感。試してないけど。
という記述がある。
これは当時間違いなく読んだ覚えがある。
ちょうどそのころに自分がコーディングしたプログラムで,何も気にせず select() を使った。
これは当時間違いなく書いた覚えがある。
Linux で root で ulimit -n 65536 という環境で動かすのが前提なのに!
そのプログラムが,きょう core を吐いて落ちた。
大量のソケットを扱うプログラムなので,ファイルディスクリプタが 1024 以上になってバッファオーパフローが起きたらしく,いろいろと楽しいことになってた。
こんな落とし穴に見事にハマるとは。
orz
Solaris なら 64 ビットでコンパイルすると FD_SETSIZE のデフォルト値が 65536 になるから問題なかったんだよなあ。
ソースコード上で FD_SETSIZE を好きな値に変更することもできたし。
と言い訳しても仕方がない。
Linux 専用の epoll を使って書き換えてみた。
select() より移植性が失われた代わりに,select() よりシンプルになった。
無駄なループが減るから性能は向上しそうだが,無駄な人的稼働を増やしてしまった。
しょぼん。