Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lock-free subscriptions #593

Merged
merged 1 commit into from
Dec 10, 2013

Conversation

akarnokd
Copy link
Member

@akarnokd akarnokd commented Dec 9, 2013

Remarks:

  • IMO, an unsubscribed Single/Serial/Multiple subscription return Subscriptions.empty() instead of null. So unless the user put a null in there he/she shouldn't worry about null.
  • There was a concurrency bug in @jloisel 's reimplementation of CompositeSubscription. It allowed multiple threads to enter the mutation part if the current state was already MUTATE. I've added the necessary checks to allow only NORMAL -> MUTATE transitions.

@jloisel
Copy link
Contributor

jloisel commented Dec 9, 2013

It cannot return Subscriptions.empty(), since the Rx contract is to return null. Also, returning empty() when unsubscribed is ambiguous: has it been unsubscribed or has empty() been set by the client code ?

@cloudbees-pull-request-builder

RxJava-pull-requests #527 SUCCESS
This pull request looks good

@jloisel
Copy link
Contributor

jloisel commented Dec 9, 2013

Good that you fixed the race condition in MultipleAssignementSubscription as well as the contract. (it was unsubscribing the previous subscription although it shouldn't)

@akarnokd
Copy link
Member Author

akarnokd commented Dec 9, 2013

I've checked the Rx.NET sources:

  • SingleAssignmentDisposable returns DefaultDisposable.Instance
  • SerialDisposabe returns null
  • RefCountDisposable returns Disposable.Empty
  • ScheduledDisposable returns DefaultDisposable.Instance

So my question is, why only SerialDisposable returns null? Checking the return of the getSubscription to determine if unsubscription happened is wrong since SerialSubscription can be started with null; this is why isUnsubscribed() is to be used to check the state.

@headinthebox
Copy link
Contributor

It cannot return Subscriptions.empty(), since the Rx contract is to return null.

I don't think that is actually this strict; that is what the implementation does; I think it is better to return empty than null. The real "state" is is isUnsubscribed (and the properties might as well be write-only)

@jloisel
Copy link
Contributor

jloisel commented Dec 9, 2013

I think the disposable / subscription contract lakes precision and uniformity. It doesn't matter to return null or empty, what matters is a constant behavior, following the "least astonishment" principle

benjchristensen added a commit that referenced this pull request Dec 10, 2013
@benjchristensen benjchristensen merged commit 80177f0 into ReactiveX:master Dec 10, 2013
rickbw pushed a commit to rickbw/RxJava that referenced this pull request Jan 9, 2014
@akarnokd akarnokd deleted the LockFreeSubscriptions branch January 13, 2014 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants