Cap'n Proto RPC リクエストを処理する Linux サーバーがあります。これらのリクエストの一部は、リクエスト内のデータを実行中の別のサーバー (この場合は Kafka ブローカー) に転送する必要があります。librdkafka と Cap'n Proto KJ ライブラリは両方とも poll() を使用できるため、OS は両方が非同期で実行できることを保証すると思いますが、さらなる統合が必要かどうか、または有益かどうかはわかりません。誰もこれを経験していますか？
質問は、私がリストした詳細よりも少し広いです.Cap'n Proto RPCから将来呼び出す可能性のある他のAPIがあるので、幅広いガイドラインをいただければ幸いです。
残念ながら、これはそれほど単純ではありません。はい、どちらも poll() を使用していますが、問題は、一度に 1 つのライブラリのみが poll() を呼び出し、そのライブラリだけが実際にイベントを受け取ることです。もう 1 つのライブラリはスタックしています。これは、イベント ループ ライブラリの典型的な課題です。デフォルトでは、これらを一緒に使用することはできません。
1 つのオプションは、ライブラリを別々のスレッドで使用することです。しかし、多くの場合、イベント ドリブン ライブラリは、単一のスレッドですべてを実行しているという前提に基づいて設計されています。そうでなければ、なぜイベント ループが必要になるのでしょうか。
しかし、「正しいこと」は、イベント ループを統合することです。KJ のイベント ループは、他のイベント ライブラリと統合できます。たとえば、node-capnp の libuv と統合しました。このファイルの最初の部分を参照してください。
https://github.com/kentonv/node-capnp/blob/master/src/node-capnp/capnp.cc
(ある時点で、ここにある libuv 関連のコードを、Cap'n Proto に同梱されている別のライブラリに分離する予定です。)
別の例として、Nathan Hourt による Qt のイベント ループとの統合を追加するためのプル リクエストがあります。ただし、これには I/O 統合が含まれていないことに注意してくださいAsyncIoStream。それは利用可能です：
https://github.com/sandstorm-io/capnproto/pull/253
いずれにせよ、Kafka が使用するものと同様のことを行う必要があります。うまくいけば、あなたのコードを Cap'n Proto に投稿してください! :)