[Q/KDB +]:qでのwaitfor(信号待ちまたはタイムアウト待ち)実装
私はq
プロセスを持っています。これは、一度に1つずつテーブルの行を別のプロセス(たとえばティッカープラント)に送ります。
feed:{h`.u.upd,x;};
feed each tbl;
条件のいずれかが満たされた場合、私は、次の行をfeed
たい:
- プロセスがそうするための他のプロセスからの信号(
next
又はready
)を受信します。
OR
-
信号待ち
- 時間がなくなる(
timeout
がtbl
の各行に固有のものであり、tbl
の列として提供される)
tbl
には、CEP /ティッカープラントの残りの部分が準備されているときに順次発行されるイベントのリストが含まれていると考えてください。または n extイベントが発行されます(timeout
は、最後に公開されたイベントと次のイベントの間のデルタタイムスパンとして測定されます。つまり、update timeout:((1 _deltas time),0Wp) from tbl
)。どちらか早く発生します。
私はwhile[.z.N<prevtstamp+timeout;wait()];feed x
を試しましたが、while
は、プロセスが他のプロセスAFAIKからの非同期メッセージを受信するのをブロックしています。と考え
その他の解決策:.z.ts
との信号のチェック
\t
は1msの精度の下に行くことができないとして遅すぎます。
(ready
)のシグナルを継続的にポーリングすると、while
ループ内のシグナルがティッカーを遅くします。
tbl
の現在の行のインデックスを維持することと、1つの条件を別々に処理し、現在のi
インデックスをポーリングする2つのプロセスにフィーダを分離することです。これは、each
行に比べて遅く聞こえます。
を回避するために、より良い設計を検討することができ、私はあなたを助けることができる任意の利用可能な 'system'呼び出しがあるかどうかわからないが、IMO qはありませんこれを行うための適切な場所。おそらくあなたにこの機能を提供するCのビットと、あなたはステータスを確認するために 'フィード'を呼び出すことができますか? –
あなたのユースケースに興味があります - IPC経由で(またはバッチで)メッセージを送信し、消費プロセスに委ねてキューを処理するのはなぜですか?このようにして、クライアントアプリケーションは、利用可能な次のメッセージをいつでも処理します。 遅い消費者に問題がありますか? – user2242865
@ user2242865ユースケースは、リアルタイムストリーミングではなく、履歴データのバックテスト(再生)です。このような懸念は、先読みバイアスと呼ばれています。遅い消費者は、より速い消費者からの情報、つまり将来の情報に対処できないはずです。 'tbl'の外部イベントの記録されたシーケンスがA、Bであり、内部的に生成されたイベントCとDが全体的なABCD順で発生したことを知っています。遅いプロセスがAを消費してCを生成すると(これを公開しているティッカープラントを更新する)、速いプロセスがBを消費してDを生成する場合、観測される順序は間違ってABDCになります。 –