-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
Observer with observeOn on Schedulers.currentThread is not called on currentThread #370
Comments
This is by design. It's your job to observe on whatever thread you want. fooService.doSomething("Hi!")
.map({ o -> o.getList() })
.observeOn(AndroidSchedulers.mainThread())
.subscribe({ adapter.setList(it); }) This is documented on
|
Are you on the JVM? I'm not familiar with the semantics of exactly how Retrofit shouldn't exhibit any behaviors that are different from normal RxJava. Internally we are just calling |
I dug a litter deeper. If I do not use the Observable return type from a service call and then wrap the response in an Observable, the observeOn and subcribeOn are performed on the correct threads. If I use the Observable return type from a service call then the onNext is not performed on the expected thread set by the observeOn(Schedulers.currentThread) but on the "Retrofit-idle" thread instead. Maybe I'm doing something wrong. |
Retrofit is behaving correctly, but RxJava can be confusing. Generally speaking you want |
Thank you loganj. I did indeed made the same mistake. |
@loganj what if you are on JVM and therefore do not have access to |
To answer the JVM question, you need an Executor that executes the runnables back on the calling thread. One solution is posting to a BlockingQueue that's being consumed on the caller's thread. Something like this (kotlin), val tasks = LinkedBlockingQueue<Runnable>()
Observable.fromCallable {"Hello" }
.subscribeOn(Schedulers.io())
.observeOn(Schedulers.from(Executor { runnable -> tasks.add(runnable) }))
.subscribe { println("Back on the original thread: " + Thread.currentThread().name) }
tasks.take().run() |
@guelo so that just basically blocks the calling thread until, |
Correct. You need some kind of strategy to allow the thread to cede control and execute work asynchronously posted from another thread. In UI and game code that's usually provided for you as an event loop, which is what |
I'm new to RxJava so forgive me if I made the wrong assumption.
I assumed from the RxJava documentation that the Observer is called from the thread which is set by the observeOn call of an Observable.
In my case I set the Schedulers as follows:
.subscribeOn(Schedulers.threadPoolForIO()).observeOn(Schedulers.currentThread())
So I was expecting that the onNext is called from the current thread but it appears that onNext is called from the "Retrofit-Idle" thread instead.
It seems that the observeOn is completely ignored.
Is this as designed or is this an error?
The text was updated successfully, but these errors were encountered: