poll と select の違いは何ですか?

select() call では、3 つのビットマスクを作成して、読み取り、書き込み、およびエラーを監視するソケットとファイル記述子をマークします。オペレーティング システムは、実際に何らかのアクティビティがあったものをマークします。 poll() 記述子 ID のリストを作成すると、オペレーティング システムはそれらのそれぞれに kind のマークを付けます。

select() メソッドはかなり扱いにくく、非効率的です。

<オール> <リ>

通常、1 つのプロセスで使用できる可能性のあるファイル記述子は 1,000 を超えます。実行時間の長いプロセスで数個の記述子しか開いていないが、そのうちの少なくとも 1 つに大きな番号が割り当てられている場合、ビットマスクは select() に渡されます。 その最高の記述子に対応するのに十分な大きさである必要があります — そのため、数百ビットの範囲全体が設定解除され、オペレーティングシステムは select() ごとにループする必要があります それらが設定されていないことを発見するためだけに呼び出します。

<リ>

一度 select() が返された場合、呼び出し元は 3 つのビットマスクすべてをループして、どのイベントが発生したかを判断する必要があります。非常に多くの典型的なアプリケーションでは、常に 1 つまたは 2 つのファイル記述子だけが新しいトラフィックを取得しますが、3 つのビットマスクすべてを最後まで読み取って、それらがどの記述子であるかを検出する必要があります。

<リ>

オペレーティング システムは、ビットマスクを書き換えることによってアクティビティについてユーザーに通知するため、ビットマスクは台無しになり、リッスンするファイル記述子のリストでマークされなくなります。メモリに保持している他のリストからビットマスク全体を再構築するか、各ビットマスクと memcpy() の複製コピーを保持する必要があります。 各 select() の後に台無しになったビットマスクの上にデータのブロック

だから poll() 同じデータ構造を再利用し続けることができるため、アプローチははるかにうまく機能します。

実際、poll() epoll() は、最新の Linux カーネルのさらに別のメカニズムに影響を与えました。 これにより、メカニズムがさらに改善され、スケーラビリティがさらに飛躍的に向上します。現在のサーバーは、一度に数万の接続を処理する必要があることが多いためです。これは、取り組みの良い紹介です:

http://scotdoyle.com/python-epoll-howto.html

このリンクには epoll() の利点を示す素晴らしいグラフがありますが ( select() に注意してください この時点で、非常に非効率的で時代遅れであると考えられているため、これらのグラフには線さえありません!):

http://lse.sourceforge.net/epoll/index.html

更新: 別のスタック オーバーフローの質問を次に示します。その回答では、違いについてさらに詳しく説明しています。

Twisted での select/poll と epoll リアクターの注意


これであなたの質問に答えられると思います:

2017 年 10 月の更新:

上記の電子メールは少なくとも 2001 年のものです。 poll() コマンドは現在 (2017 年)、BSD を含むすべての最新のオペレーティング システムでサポートされています。実際、select() と信じている人もいます。 非推奨にする必要があります。意見はさておき、poll() あたりの移植性の問題 最新のシステムではもはや問題ではありません。さらに、epoll() はその後開発され (man ページを読むことができます)、人気が高まり続けています。

最新の開発では、おそらく select() を使用したくないでしょう 、明示的に問題はありませんが。 poll() 、そしてそれはより現代的な進化です epoll()select() と同じ機能 (およびそれ以上) を提供します その制限に悩まされることはありません。