# subscribeOn Published articles for subscribeOn. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From RxJava 2 to Kotlin Flow: Threading DevFeed: [From RxJava 2 to Kotlin Flow: Threading]() Original publisher: [Read original article]() Published: 2020-01-25T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [RxJava](), [kotlin-flow](), [Kotlin](), [Concurrency](), [reactive](), [Parallelism](), [Android](), [Programming]() Tags: [android](), [concurrency](), [kotlin](), [kotlin-flow](), [observeon](), [parallelism](), [reactive](), [reactive-programming](), [rxjava](), [streams](), [subscribeon]() ### AI overview This article compares threading in RxJava 2 and Kotlin Flow. It explains cold streams and the roles of subscribeOn and observeOn, including how schedulers determine where a reactive chain starts and continues. ### Source excerpt Source Introduction For a long time RxJava was undisputed leader for reactive solutions on Android, though with Kotlin expansion and introducing cold streams (Flow) seems situation might be rapidly changing in the coming years. Though reactive programming is not related to threading in the first place, concurrency and parallelism are very important anyway. In this article we'll try to make short recap on threading in RxJava 2 (with some basic caveats on its usage) and then take a look at how threading works in Kotlin Flow, so if anyone would like to migrate their code without affecting functionality it would be nice and smooth. ## When multiple subscribeOn()s do have effect DevFeed: [When multiple subscribeOn()s do have effect]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-11-29T12:33:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Code](), [Concurrent Programming]() Tags: [collect](), [concurrency](), [filter](), [flowable](), [io](), [main-thread](), [map](), [scheduler](), [subscribeon](), [take](), [thread](), [tutorials]() ### AI overview This article explains why multiple subscribeOn() operators can sometimes have observable effects. It distinguishes source operators that perform subscription side effects from instance operators that mainly subscribe upstream, and shows how different schedulers can determine the threads where those effects occur. ### Source excerpt Introduction In many tutorials and explanations, it has been said that having multiple subscribeOn()s has no effect and only the one closest to the source wins. I often tell this with the wording "no practical effect". However, it is possible to demonstrate the effects of multiple subscibeOn()s that have some actual effects. What is subscribeOn again? The most precise definition of this operator I can formulate is as follows: subscribeOn changes where (on what thread) the (side) effects of calling subscribe() on the parent/upstream Observable (Flowable, Single, etc.) happen. So what are these subscription (side) effects look like in code? Observable.create(emitter -> { for (int i = 0; i < 10; i++) { emitter.onNext(i + ": " + Thread.currentThread().getName()); } emitter.onComplete(); }) .subscribeOn(Schedulers.io()) .blockingSubscribe(System.out::println); // Prints: // ------- // 0: RxCachedThreadScheduler-1 // 1: RxCachedThreadScheduler-1 // 2: RxCachedThreadScheduler-1 // 3: RxCachedThreadScheduler-1 // 4: RxCachedThreadScheduler-1 // 5: RxCachedThreadScheduler-1 // 6: RxCachedThreadScheduler-1 // 7: RxCachedThreadScheduler-1 // 8: RxCachedThreadScheduler-1 // 9: RxCachedThreadScheduler-1 In this example, the effect of subscribing is that the body of the ObservableOnSubscribe starts running on the thread provided via the io() Scheduler. Applying yet another subscribeOn after the first one won't change what is printed to the console. Most source-like operators, such as create(), fromCallable(), fromIterable(), do have subscription side-effects as they often start emitting event(s) immediately. Most instance operators, such as map(), filter(), take(), don't have subscription side-effects on their own and just subscribe() to their upstream. Instance operators with subscription side-effects However, there are a couple of instance operators that do have subscription side-effects. Specifically, any operator that offers a way to specify a per subscriber initial state via ## SubscribeOn and ObserveOn DevFeed: [SubscribeOn and ObserveOn]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2016-03-31T12:55:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Programming](), [reactive](), [User Experience](), [Android](), [GUI]() Tags: [backpressure](), [blocking](), [cancellation](), [executorservice](), [main-thread](), [observeon](), [reactive](), [rxjava](), [subscribeon](), [thread]() ### AI overview A tutorial explaining why RxJava's subscribeOn and observeOn operators are often confused. It distinguishes their effects by tracing subscription and method-call flow, and discusses moving subscription side effects such as network, database, or blocking work away from the current thread. ### Source excerpt Introduction One of the most confused operator pair of the reactive ecosystem is the subscribeOn and observeOn operators. The source of confusion may be rooted in a few causes: they sound alike, they sometimes show similar behavior when looked at from downstream and they are duals in some sense. It appears the name-confusion isn't local to RxJava. Project Reactor faces a similar issue with their publishOn and dispatchOn operators. Apparently, it doesn't matter what they are called and people will confuse them anyhow. When I started learning about Rx.NET back in 2010, I never experienced this confusion; subscribeOn affects subscribe() and observeOn affects onXXX(). (Remark: I've searched Channel 9 for the early videos but couldn't really find the talk where they build up these operators just like I'm about to do. The closest thing was this.) My "thesis" is that the confusion may be resolved by walking through how one can implement these operators and thus showing the internal method-call flow. SubscribeOn The purpose of subscribeOn() is to make sure side-effects from calling subscribe() happens on some other thread. However, almost no standard RxJava source does side-effects on its own; you can have side-effects with custom Observables, wrapped subscription-actions via create() or as of lately, the with the SyncOnSubscribe and fromCallable() APIs. Why would one move the side-effects? The main use cases are doing network calls or database access on the current thread or anything that involves blocking wait. Holding off a Tomcat worker thread hasn't been much of a programming problem (that doesn't mean we can't improve the stack with reactive) but holding off the Event Dispatch Thread in a Swing application or the Main thread in an Android application has adverse effect on the user experience. (Sidenote: it's a funny thing that blocking the EDT is basically a convenience backpressure strategy in the GUI world to prevent the user from changing the application state whil