4

エッジ トリガー モード ( )でLinux epollを使用し、読み取り/書き込みが/でEPOLLET失敗した場合、読み取り/書き込み準備が失われ、準備が整うとすぐに新しい準備イベントが使用可能になることが保証されていることを意味します。取り戻した。EAGAINEWOULDBLOCKepoll_wait()

さらに、エッジ トリガー モードでLinux epollとノンブロッキング ストリーム モード ソケットを使用し、EPOLLRDHUPイベントへの関心を登録し、EPOLLRDHUPイベントがまだ受信されていない場合、短い読み取り/書き込み (要求されたサイズよりも小さい戻り値) ) は、読み取り/書き込み準備が整っていないことも意味します。また、準備が回復したときに、 / で読み取りEAGAIN/書き込みが失敗したことがなくても、新しい準備通知を信頼できますEWOULDBLOCK。

同様に、エッジ トリガー モード ( ) でKqueue (macOS/FreeBSD) を操作し、読み取り/書き込みが/でEV_CLEAR失敗した場合、読み取り/書き込み準備が失われ、新しい準備イベントが利用可能になることが保証されていることを意味します。準備が整い次第経由。EAGAINEWOULDBLOCKkevent()

質問:エッジ トリガー モードでKqueueとノンブロッキング ストリーム モード ソケットを使用する場合EV_EOF、イベントへの関心を登録し、EV_EOFイベントがまだ受信されていないという条件で、同様の保証がありますか?読み取り/書き込み準備が失われ、準備が回復したときに新しい準備イベントが生成されることが保証されていることを意味しますか?

編集：注：短い読み取りは読み取り準備の喪失を意味することを知っていると、（一般的な場合に）/失敗read()を取得するためだけの冗長な呼び出しを回避できます。EAGAINEWOULDBLOCK

Linux epoll のコンテキストでの短い読み取り/書き込みの意味は、epoll(7) man ページのこのコメントから得られます。

ストリーム指向のファイル (例: パイプ、FIFO、ストリーム ソケット) の場合、読み取り/書き込み I/O スペースが使い果たされている状態は、ターゲット ファイル記述子から読み書きされたデータの量をチェックすることによっても検出できます。たとえば、特定の量のデータを読み取るように要求して read(2) を呼び出し、read(2) がより少ないバイト数を返す場合、ファイル記述子の読み取り I/O スペースを使い果たしたことを確認できます。write(2) を使用して書き込む場合も同様です。(監視対象のファイル記述子が常にストリーム指向のファイルを参照することを保証できない場合は、この後者の手法を避けてください。)

4

1 に答える 1

1

「エッジ トリガー モードのKqueue」について尋ねますが、kqueue のドキュメントではその用語は使用されていません。EV_CLEAR問題のイベントのフラグを有効にしたことを意味していると思います。

ユーザーがイベントを取得すると、その状態はリセットされます。

(の BSD ドキュメントkqueue())

さらに、あなたはプログラムが持っていることを規定します

イベントへの関心が登録されEV_EOFており、EV_EOFイベントがまだ受信されていないこと

しかしEV_EOF、それ自体はイベントではありません。むしろ、使用可能なフィルターの一部が適切なときに設定するフラグですEVFILT_READ。

とにかく、あなたの質問の核心は

短い読み取り/書き込みは読み取り/書き込み準備の喪失を意味し、準備が回復したときに新しい準備イベントが生成されることが保証されるという同様の保証はありますか?

私が判断できる限り、短い読み取りが読み取り準備ができていないことを示すという保証は、BSD でも Linux でもありません。実際、read(2)短い読み取りの考えられる別の理由として、シグナルの受信を具体的に呼び出している Linux のドキュメントがあります。

epoll()さらに、エッジ トリガー モードでの非ブロッキング ファイル記述子に対してLinux ドキュメントが推奨する使用モデルはEAGAIN、読み取りが で失敗するまで繰り返し読み取ることです。有効なイベントについては、kqueue システムと同じポリシーに従うことをお勧めEV_CLEARします。

短い読み取りで停止することで 1 つの呼び出しを節約することを望んでいたことは認識していますread()が、それは、着信データ ストリームを無期限にサービスされないままにするプロセスの真正なリスクを最小限に抑えると思います。さらに、これらの余分な読み取りが測定可能で許容できないパフォーマンスの低下の原因であると判断しない限り、懸念は時期尚早です。

于 2016-10-27T22:54:23.223 に答える