You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If some buffering is desired however, it would probably be incorrect to add it after the merge, because you can buffer lower-priority items, and keep the high priority items from being processed.
So I'd like us to open an issue for a buffered variant too. I'm thinking that each priority can have its own buffer and then a loop would go and select between them, cycling from high priority to low priority.
... speaking of this, this is how RxJava built a kick-ass merge operation, last time I checked. They created multiple buffers (concurrent queues), assigning them per observable being merged, to reduce the contention on the producers side. But this isn't very relevant to this PR. Mentioning it to keep it in mind for the future.
Alternatively, if we follow our current implementation of merge, we could probably do it with PriorityQueue-based implementation of BufferedSubscriber.
Per discussion in #1205.
#1202 provides for merging observables with a fixed, subscriber-backpressure-propagating strategy.
The text was updated successfully, but these errors were encountered: