1.x: CombineLatest now supports any number of sources #3661
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks! |
|
👍 |
akarnokd
added a commit
that referenced
this pull request
Feb 3, 2016
1.x: CombineLatest now supports any number of sources
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a backport of the 2.x
combineLatestwithnullsupport and let's the programmer combine more than 128 sources at once. Note that 2.x supports manual sizing of the prefetch buffer and allows delaying the exceptions to the last moment; I kept these in case such features are required by 1.x some day.The original had this 128 limit due to using a single and non-parametric RxRingBuffer to store values from sources. In addition, the original algorithm divided downstream requests among the sources with some strange logic in order to keep them running and not overflow the buffer.
This PR uses an unbounded-linked SPSC queue which can now hold as many elements as there are sources times the default ring buffer size (this is not preallocated and grows/shrinks as necessary).
The algorithm stores the current latest array and the source subscriber in the queue in pairs so when that particular row is emitted to downstream, that source subscriber gets the request() replenishment call that generated the row.
In addition, I've added an Iterator overload from #3660 as well.