Linux下select使用陷阱

Select函數使用簡單，其工作原理大家通常也知道，但是在實際的使用過程中可能並沒有嚴格遵守，而且確實也比較難以完全遵守，除非不使用它。

Select採用一個bit表，每個fd對應表中的一個bit位，宏FD_SETSIZE為表的大小，添加到fd_set中的fd值必須小於FD_SETSIZE，否則就會越界，假設有如下一段代碼：

fd_set  readfds;

FD_ZERO(&readfds);

FD_SET(fd,  &readfds);

那麼，這裡的fd必須滿足：fd < FD_SETSIZE，否則即會發生越界，使用valgrind和purify等記憶體偵查工具能夠檢測到這個問題，但通常很少人去注意，會認為是一個可以忽略的warning，其後果是導致某個不能理解的crash問題。

通過ulimit命令和setrlimit函數來修改進程內控制代碼數的限制，並不會影響FD_SETSIZE的值，所以即使通過ulimit命令或setrlimit函數將進程允許的控制代碼改成很大了，但如果FD_SETSIZE值沒有修改，則仍可能發生crash。

在什麼情況下最容易遇到這個問題？

較容易發生在服務端程式中，因為服務端程式同一時刻的串連數很容易超過預設的FD_SETSIZE值，而服務端的代碼可能是使用epoll使用的，所以它本身並不會存在問題，但是程式中可能還有個用戶端，比如使用了select來實現逾時串連，這個時候問題就來了，當串連數超過FD_SETSIZE時，逾時串連處的select調用就發生了越界，進程就會在某個可能完全不相干的地方crash，要定位這個問題的成本是很高的，不具備一定經驗，很難在短時間內定位出來。

如何去避免這個問題了？那就是盡量不使用select，而應當使用更安全的poll函數來替代，因為poll使用的數組是調用者自己維護的，完全可以保證不越界。