Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider the following code:
My expectation was that the
The ReactiveX blurb for zip doesn't actually claim that the Observable created by
The following example seems even more directly strange:
No matter how many tokens you stuff in the
Commit ba41245 of April 4, 2018
iOS and macOS, at least
How easy is to reproduce? (chances of successful reproduce after running the self contained code)
But also happens if you just clone the RxSwift project and paste the code into one of the playgrounds.
I have multiple versions of Xcode installed:
Yes; Xcode 8.3.3 and Xcode 9.4. But I hardly ever touch 8.3.3
Level of RxSwift knowledge:
Hi @GarthSnyder ,
The reason why
Unfortunately, both the current behavior, and the one you are suggesting can be improved.
We actually shouldn't complete
Also, current behavior assumes that observable sequences used as a source for
We'll remove any types of "playing smart" code from
Ah, very interesting! Thanks for taking the time to write up this detailed explanation.
In my (current) use case, the extra things being zipped are just tokens (hence the name "gate" above). So, for example, if there are 20 tokens available, only 20 items can be in a particular stage of the pipeline at once. Items consume a token when they enter the critical section (by being zipped with the token stream) and put a token back in the token stream when they leave the critical section (by calling the token-stream Subject's
It seems to work great except for the fact that the main pipeline can never complete. Is there a more idiomatic RxSwift way to achieve this effect?
It looks like the
(Details that probably aren't all that relevant/important: the application gathers XML feeds for podcasts from the web. Search terms from a static list go in the head of the pipeline, where they are transformed into search results that point to individual feeds. Then later stages of the pipeline read and parse those feeds, emitting a stream of parsed XML documents.
Even though this is a totally static workload, it actually works very well as an RxSwift pipeline because RxSwift allows easy retrying of individual network requests with various parameters (e.g., HTTP user agent) and handles database deadlocks elegantly (just abort the current transaction, back up, and retry parsing). But the pipeline can't be allowed to kick off 200 URLSessionDataTasks at once. :-)
Hi @GarthSnyder ,
Backpressure adds tons of complexity, unpredictability and would slown down the implementation considerably IMHO.
I believe that the primary motivation for backpressure were Netflix's streaming use cases. That's the only information I have. In that context it makes sense, and it seems to me that it's even optimized for that use case. That also means that it's not optimized for bunch of other use cases which are far more common.
You could probably use backpressure to solve some of your problems, yes, but the possibility of doing that doesn't necessarily prove that you should.
I believe that latest RxJava separates Flowable from Observable, and I think this is an awesome decision.
I don't believe that adding Flowable to this repo is an efficient investment of time and it has far more downsides then upsides, so I would really want to stay away from Flowable in the foreseeable future.
If one wanted to prevent zip from completing if one observable completed, it would have been easier to
How do you recommend one replicates the old behavior now?
No, the old behavior was wrong.
Writing your own implementation or doing