.toBlocking never finishing when using .observeOn(AndroidSchedulers.mainThread()) about rxandroid HOT 9 CLOSED

It works if you leave off the observerOn which I would imagine is still running on the UI thread, so that's why I would expect this to work. The reason I am looking for this functionality is for in a widget, there are certain calls that need to be completed before the next life cycle event. I'll look into a better way of handling that, instead of doing this.

from rxandroid.

Let me guess - it only happens if you call toBlocking().first() from the UI thread, but works as expected in background thread? If so, it's a HandlerThreadScheduler bug - it always post actions to the end of the processing queue and doesn't check if action can be executed right now. There were multiple pull-request with a fix, but all of them were rejected for some reasons.

from rxandroid.

Yeah, using first() or getFuture().get() both cause this issue.

from rxandroid.

Relevant: ReactiveX/RxJava#1102

from rxandroid.

What we could do is introduce a new Scheduler that allows for this optimization. At least then it's made clear in the type that events would not always enter Android's message loop?

For instance we could introduce a specialization of HandlerThreadScheduler (say UIScheduler) that is already bound to the main looper and which performs synchronous dispatches if you're already on the main thread. Or we could introduce a piece of configuration that allows HandlerThreadScheduler to "short circuit" if it's already on the relevant thread. I just want this to be made explicit in some way shape or form, since otherwise this opens the flood gates for all sorts of weird race conditions and unpredictable behavior.

from rxandroid.

@mttkay I am in favor of this. I guess I don't have an opinion of which route to take, but I agree with the explicitness. Do you envision it changing the above example to be like subject.observeOn(Schedulers.uiScheduler()).take(1).toBlocking()?

from rxandroid.

Yes; if we think it's valuable enough to have this optimization in place as a default, I would even argue it might be worth doing a breaking change and default mainThread() to use it. In those cases where recursive scheduling is involved, this would be a breaking change, but I reckon in the vast majority, people would simply not notice it and can enjoy the benefits.

We're still in 0.x mode, so if we feel a breaking change is necessary, I would do it sooner rather than later.

from rxandroid.

I took a stab at this, and am coming up blank. I am starting to think that this is expected behavior. I believe what is happening is the handler is blocked by the toBlocking, and cannot continue processing messages until that is freed up.

from rxandroid.

@pieces029 That is expected for me as well.

@mttkay Since the UI thread is blocked in first(), how could a special UiScheduler work unless the BlockingObservable.first() (and others) operator is special-cased to execute queued messages? Wouldn't that be a nightmare?

Note: blocking the UI thread is bad, and it should never be executing toBlocking().first() in the first place.

from rxandroid.