| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
I'll have to allocate some time to review this later as it is somewhat detailed. Thank you for tackling this. |
Sorry, something went wrong.
That was done by design, since scalars behave as onNext. And we can limit the number of Observables being merged if we have scalars queued up for delivery. The reason we can't limit the number of async Observables is because we don't know if they will emit or not and thus risk deadlock. |
Sorry, something went wrong.
I forgot to add the choice because 2.x SpscArrayQueue doesn't use Unsafe. I copied the SpscAtomicArrayQueue from ReactiveX#3169 and I hope it won't conflict.
|
👍 |
Sorry, something went wrong.
|
I'll rebase this. |
Sorry, something went wrong.
|
Rebased, let's get this finally in. |
Sorry, something went wrong.
Merge can now operate in horizontally unbounded mode.
|
Thanks |
Sorry, something went wrong.
I forgot to add the choice because 2.x SpscArrayQueue doesn't use Unsafe. I copied the SpscAtomicArrayQueue from ReactiveX#3169 and I hope it won't conflict.
| Back | FazBrowse Home | New Git URL |
Resolves #3156
Note that since the default merge operation is unbounded, this change could lead to an excessive memory usage when flatMapping fast sources. Note that the pre 1.0.13 version did this albeit on a slighty slower path.
The change also affects the scalar optimization as well. Pre 1.0.13 implicitly limited the concurrency level to RxRingBuffer.SIZE when scalars were received. This version now fills the queue up to the concurrency level.
For 2.0, I suggest having a bounded behavior by default and require the developer to specify Integer.MAX_VALUE to go for the unbounded behavior so he/she knows about the consequences.