>>780
>でもこのアプリはマルチスレッド＆非ブロッキングなんですよ。

>>764に挙げたのはselectによるタイマ監視を使用しない、一般的なケースですね。
もし>>750のようにタイマ監視が前提であれば、receiveによるプロセスのブロックは
selectによる監視の妨げになりますから、非ブロッキングなreceiveを使います。
ソケットは1個でも、そのデータ受信イベントとタイムアウト発生イベントを
同時に待ち受けるわけですから、selectの利用は自然な発想だと思います。

あと>>750で気になったのは、acceptをSleepとのループで待っているとの記述です。
acceptも(receiveと同じように)TCPコネクション確立通知イベント発生をタイムアウト付きで
selectを用いて監視できます。Sleepというのが何なのか分かりませんが(おそらくは独自の
マクロかライブラリ関数？)、C標準ライブラリのsleep関数に相当ものであると仮定すれば、
sleepによる待ち時間は無駄ですから、TCPコネクション確立通知に対する応答時間を
遅延させるだけの意味しか持たないように思えます。だから一般的にはタイムアウト付きの
selectでacceptをループさせます。謎のSleepについて、調査する必要があるかもしれません。

(長いので続く)