問題タブ [kqueue]

kqueue メカニズムにはEV_RECEIPT、リンクされたマニュアル ページによると、イベント フラグ があります。

...保留中のイベントを排出せずにkqueueを一括変更するのに役立ちます。入力として渡されると、EV_ERROR常に返されるように強制されます。フィルタが正常に追加されると、データ フィールドはゼロになります。

neventsただし、パラメーターに0 を渡しkeventてキューからイベントを描画しないだけで、保留中のイベントを排出せずに kqueue を一括変更するのは簡単だと理解しています。それを念頭に置いて、なぜEV_RECEIPT必要なのですか？

OS X に関する Apple ドキュメントの一部のサンプル コードでは、実際に EV_RECEIPT を使用しています。

しかし、changes配列は呼び出し後に検査されないため、この場合にkeventなぜ使用されたのかはまったくわかりません。EV_RECEIPT

EV_RECEIPT は実際に必要ですか? 本当に役に立つのはどんな場面？

GOを使用して、プロセス (親ではない) が終了したかどうかを確認しています。基本的には、 FreeBSDのpwaitコマンドのようなものですが、go で記述されています。

for loop現在、で を試していますが、このアプローチでは CPU 使用率が99%kill -0と非常に高いことに気付きました。コードは次のとおりです。

これを改善または適切に実装する方法についてのアイデア。

前もって感謝します。

アップデート

提案されているようにループ内に a を追加するとsleep、負荷の軽減に役立ちます。

提供されたリンクから、既存の pid にアタッチできるようです。PtraceAttachを試してみますが、これに副作用があるかどうかはわかりません。

示唆されたように、私はkqueueを使用することができました:

正常に動作しますが、Linux では利用できないと思うので、Linux で同じことを実装/達成する方法を知りたいのkqueueですが、何かアイデアはありますか?

エッジ トリガー モード ( )で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) を使用して書き込む場合も同様です。(監視対象のファイル記述子が常にストリーム指向のファイルを参照することを保証できない場合は、この後者の手法を避けてください。)