njoin処理前にデータをプリフェッチするのはなぜですか? プロセスのプロセスがどのようにマージされるかに関係がない限り、それは不必要な複雑さのように思えますか?
新しい要素が生成されるたびにエフェクトを実行するストリームがあります。私は効果を最小限に抑えたいのでnjoin、たとえばmaxOpen = 44 を同時に生成する要素の最大数にする必要があります (すぐに処理できない限り、要素は生成されません)。
これを優雅に解決する方法はありnjoinますか？現在、「チケット」の制限付きキューを使用しています (要素は、チケットを取得した後にのみ生成されます)。
https://github.com/scalaz/scalaz-stream/issues/274、具体的には以下の djspiewak からのコメントを参照してください。
「概念レベルから見ると、ここでの問題は、プロセスの「プル」モデルと、同時ストリームのマージに必要な「プッシュ」モデルとの間のインターフェース ポイントです。wye と njoin の両方がこの境界点に位置し、ソース プロセスをアクティブにプルしてインバウンド キューを満たし、結果をアウトバウンド キューにプッシュし、出力プロセスのプルを保留します (明らかに、wye と njoin の両方が、インバウンド キューを Actor を介して暗黙的にします)。また、ユーザーが気にするほとんどのプロパティ (終了の伝播、背圧など) を保持します。」
njoined の 2 番目のパラメーターである maxQueued は、プリフェッチの量を制限します。そのパラメータが 0 の場合、キュー サイズに制限がないため、プリフェッチにも制限がありません。njoin を呼び出す mergeN のドキュメントでは、このプリフェッチ動作の理由がもう少し詳しく説明されています。「内部的にmergeNは、アクティブなソースストリームの数に等しい場所nの値まで先読みする小さなバッファを保持します。これは、すべてのプロセスがこの先読みキャッシュで参照されることを意味しません。プロセスが提供するAnsourceAnjoin は、すべてのソースがほぼ同時に値を提供した場合に何が起こるかという問題に対処しているように見えますが、これらの結合されたストリームのいずれかが遅いストリームを締め出すのを防ごうとしています。 .