Hideaki Kondo
kondo****@oss*****
2007年 5月 28日 (月) 15:35:14 JST
中居様、佐々木様 お世話になっております。 近藤と申します。 UM-L7の今後の開発に関する情報提供と epoll化に関するコメント有難うございます。 私も少しコメントさせていただきます。 > エッジトリガ・イベントトリガともに、epoll_wait()のevents配 > 列へ、先頭から順に発生したイベントのみを設定してくれるため、差 > 異はなく、イベントトリガであっても全FDの走査は不要だと思います。 ・・・ ・・・ > 前述のイベント有無調査と再recv()処理で、どちらが優位か分か > らないのですが、エッジトリガを採用するならば、この辺も考慮さ > れて設計された方が良いと思います。 佐々木さんから頂いたコメントの中で 気になる点は、この部分ですね。 epoll()のエッジトリガ(ET)とselect()との 性能差は中居さんの検証により優位性は ほぼ確認できた状況ですが、佐々木さんの コメントを見ますと、同じepoll()でETとLT( レベルトリガ)の性能差（コスト差）は微妙で あまり差がない可能性がありますね。 epoll_wait()のevents配列に対して先頭から順に 発生したイベントのみを設定してくれるため、 エッジトリガと差異はなく、イベントトリガで あっても全FDの走査は不要という点は、私は 少し認識違いしておりました。（もともとepoll化 のメリットはこの点が大きい思ってましたので、 LTの場合でもやはりこの点は同じなんですね。） サンプルプログラム等で可能ならば、ETとLTで 性能差を比較してみたいところです。 机上から考えると、扱うデータサイズによって ETとLTの優位差が変わってきそうですね。 扱うデータサイズが大きい（受信を複数回繰り返す） ケースでは、イベント再登録が不要なLTの方が優位で、 逆に一度で受信できてしまうようなデータサイズが 多いケースでは、ETの方が優位という感じですかね。 > epollをサポートすることは大賛成なのですが、「epollへの変更」 > ということは、selectは無くしてしまうのでしょうか? > > 今後もLinuxしかサポートしないというならば、それで良いと思いま > すが、他OSへの移植なども考えにあるならば、selectも残しておい > ても良い気がします。 この件も、確かに考慮したい点だと思いますが、 ETを利用する場合、変更は比較的大きいと思いますので いきなり両方に対応するのは厳しいでしょうね。 まずはepoll化に専念し、今後他OSへの移植等必要に応じて select対応は考えていくのが良いのではないかと思います。 以上です。 -- Hideaki Kondo
UltraMonkey-L7
Fork