Delay #2
Open
Delay #2
Conversation
This file contains hidden or 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
Fixed the issues of takeLast(items, 0) and null values
Implemented the 'SkipLast' operator
Implemented the 'Empty' operator with scheduler
JRuby function wrapping support
The PublishSubject implementation was performing onError/onCompleted unsubscribe logic that was put in place long ago and I am now pretty sure it was wrong. This was revealed while playing with `refCount` which intends on allowing a re-subscription to the source once new Observers arrive. PublishSubject was preventing that. The one use case that I'm still wondering about though is if someone subscribes to a PublishSubject after it has emitted onCompleted and isn't "restarted". That Observer would wait forever if it is a "single-shot" PublishSubject use case. I'm not sure if that's just a bad use and fits into the "don't do that" scenario, or if it's a legit issue that has a solution. Rightn now this code is "thread-safe" in the visibility sense, but it's not atomic and could have race conditions between adding/removing Observers and event notifications. I don't think that's an issue as if someone is concurrently adding/removing it's always a race, but am not 100% sure if there's a use case I'm missing. This also assumes (as it always did) that someone is not invoking onNext concurrently as that would break the Rx contract.
Implemented the 'IgnoreElements' operator
Implemented the 'Throw' operator with scheduler
…-resubscribe PublishSubject ReSubscribe for publish().refCount() Behavior
Commenting out rspec until until internal Netflix build system can handle ruby gems so that I can build and release 0.14.3
We decided it's better to leave it to the caller when it's appropriate to release, cf. jmhofer#1
We decided it's sufficient for the callback to be safe as long as the caller unsubscribes in onDestroy
Operation Join again
- They were not correctly emitting onCompleted when new Observers subscribed after the Subject was terminated. - Added same logic that already existed on AsyncSubject
BugFix: Handling of Terminal State for Behavior/Publish Subjects
…pull-513-toMap Conflicts: rxjava-core/src/main/java/rx/Observable.java
Manual Merge of toMap/toMultiMap
improve javadocs, including diagrams and wiki links for new operators
- no further events expected after unsubscribe
Implicit conversions
|
Thanks! - Though maybe this works better as a new PR directly against RxJava. I'll take a look, but unfortunately, I don't have much time right now. There's also still some queueing necessary in order to properly fulfil the Rx contract, I think. |
|
I opened it as a PR on original repo: ReactiveX#384 |
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.
Hi, this is rebased on Netflix/RxJava/master like requested in the your pull request.
I'm considering opening it as a second PR on RxJava if you can't get to it.