Comments (9)
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.
Related Issues (20)
- move from version 2 to version 3 HOT 2
- BUG with gradle 3.6.1 and RxJava and RxAndroid 3.0.0 HOT 2
- RX Android & Release apk HOT 1
- RxAndroid
- HandlerScheduler throws NPE on schedule() in tests HOT 4
- AndroidRuntime: FATAL EXCEPTION -> observeOn(AndroidSchedulers.mainThread()) HOT 5
- Bug or Help Long running observable in background crashes app HOT 1
- [email protected]: Permission denied (publickey). HOT 1
- java.lang.NoSuchMethodError HOT 17
- IllegalAccessError: FlowableDoOnLifecycle: 2.2.3 HOT 1
- docs/content/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request.md
- Gi
- issue with the indirect dependency component reactive-stream License HOT 2
- Does RxAndroid have any plans to release a new version? HOT 1
- Add Sonatype secrets to repo for GitHub Actions usage HOT 9
- RxAndroid 3.0.1 NPE in JVM unit tests HOT 1
- ERROR: Failed to resolve: io.reactivex.rxjava3:rxandroid:3.0.2 HOT 5
- Sms2
- Why the HandlerScheduler class overrides scheduleDirect. It's not more explicit to let the HandlerWorker do the work HOT 4
- Kotlin multiplaform support HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rxandroid.