-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Force ViewObservable be subscribed and unsubscribed in the UI thread #880
Force ViewObservable be subscribed and unsubscribed in the UI thread #880
Conversation
RxJava-pull-requests #811 SUCCESS |
RxJava-pull-requests #812 SUCCESS |
Seems like a good change. Do you agree with the assessment in #869 that we can't guarantee a |
Force ViewObservable be subscribed and unsubscribed in the UI thread
Yes, I agree with it. Since we can not give the guarantee, it's better to require users write a thread-safe Subscription. |
Cool, then yes, I also agree that |
Working with @headinthebox based on discussions at ReactiveX#869 and ReactiveX#880 (comment) we determined that there are times when `unsubscribeOn` behavior is needed. The `subscribeOn` operator can not mix `subscribe` and `unsubscribe` scheduling behavior without breaking the `lift`/`Subscriber` behavior that allows unsubscribing synchronous sources. The newly added `unsubscribeOn` operator will not work with synchronous unsubscribes, but it will work for the targeted use cases such as UI event handlers.
Working with @headinthebox based on discussions at ReactiveX#869 and ReactiveX#880 (comment) we determined that there are times when `unsubscribeOn` behavior is needed. The `subscribeOn` operator can not mix `subscribe` and `unsubscribe` scheduling behavior without breaking the `lift`/`Subscriber` behavior that allows unsubscribing synchronous sources. The newly added `unsubscribeOn` operator will not work with synchronous unsubscribes, but it will work for the targeted use cases such as UI event handlers.
I was wondering, can we simply make the component refs volatile instead? I mean, you control the subscription, so scheduling on the UI thread just to maintain correctness w.r.t. visibility seems wasteful. |
@@ -39,6 +43,7 @@ public OperatorCompoundButtonInput(final CompoundButton button, final boolean em | |||
|
|||
@Override | |||
public void call(final Subscriber<? super Boolean> observer) { | |||
ViewObservable.assertUiThread(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is ViewObservable
? Did that land in another PR?
I would prefer to not have this call here. What we want to do instead is, if at all, check this in the fromFragment
/ fromActivity
helpers (see discussion in #754 which asks to remove this assertion entirely)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to make sure that subscribe
happens in the UI thread or there would be some concurrent issues. So I add assertUiThread
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we just add it in the helpers, users still can subscribe
in other threads after they get the Observable
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ViewObservable
is from #783
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "some concurrent issues"? We've had no issues so far
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that create an Observable in the UI thread and subscribe it on other thread. For example, Schedulers.newThread()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g., ViewObservable.clicks(..).subscribeOn(Schedulers.newThread()).subscribe(...)
Yes, I think this is better, and we can remove the |
@mttkay , I feel uncomfortable that the |
I had a local branch where I did all the changes, but I had to drop it like 2 times due to all the things that happened on master to the core APIs, that's why I suggested to hold off with changes to this. Looking at master, it seems things have stabilized and the release will go out soon. My suggestion again is:
Does that make sense? |
w.r.t. subscribing more than once: what would you expect instead? I haven't thought about this to be honest |
e.g.,
|
what doesn't work exactly? |
So the following will fail if it runs in a background thread?
|
|
Another case is:
|
I see what you mean; because I agree in general it should behave in the same way as the underlying sequence; so if the underlying sequence is re-subscribable (not all are, depending on the subscription I guess), we should probably reflect that. I'm not sure how you would solve that though. Any ideas? |
According to #869 ,
unsubscribe
can run in any thread. However, that will cause some concurrent issues in rxjava-android.This PR schedules the
unsubscribe
action to run in the UI thread to solve the problem.