Understanding subscribeOn

510 views
Skip to first unread message

Daniel Lew

unread,
Apr 9, 2015, 9:06:29 AM4/9/15
to rxj...@googlegroups.com
Hello,
I'm working on improving my understanding of subscribeOn. In particular, I'm curious why multiple calls to subscribeOn yields no results (it only registers the first call):

Observable.just(1, 2, 3)
    .subscribeOn(Schedulers.newThread())
    .subscribeOn(Schedulers.io())
    .subscribe(System.out::println);

Everything ends up on whatever Schedulers.newThread() produces. This is different from observeOn, which allows multiple calls for switching schedulers.

The only way I've figured out to switch the subscribeOn Scheduler is to use flatMap and use subscribeOn for the return Observable. It doesn't entirely make sense to me why that works when this won't work: subscribeOn().flatMap().subscribeOn()

I know these are somewhat contrived examples, as I don't have a particular use for this. I'm just trying to understand RxJava better.

Thanks,
Dan

Dávid Karnok

unread,
Apr 9, 2015, 9:23:02 AM4/9/15
to rxj...@googlegroups.com
SubscribeOn changes where the subscription happens. You can apply it multiple times but the actual emission will take place on the scheduler which is the closest to the source. All intermediate subscribeOn() are logically no-ops but they have some overhead/side effect: for example, applying newThread 3 times will start 3 new threads for the duration of the source.

flatMapping over a source with subscribeOn works because flatMap subscribes to sources beyond your subscription to flatMap. Adding subscribeOn after flatMap only changes where flatMap itself will subscribe to its main source (not the inner observables) so again multiple subscribeOn don't do too much.

The question is, why do you want to swing the subscription around?

Daniel Lew

unread,
Apr 9, 2015, 9:40:47 AM4/9/15
to rxj...@googlegroups.com
It's not that I *want* to do so, I'm just curious. I'm especially interested in the idea that you might assign a default subscribeOn, then let the caller decide the true subscribeOn later - but obviously that pattern won't work, since the first subscribeOn wins. This is all a compelling argument for never calling subscribeOn until you're actually about to subscribe, though.

That's interesting about creating new threads for the duration of the source. I would've thought they'd be total no-ops, given that they effectively do nothing.

-Dan

Cédric Beust ♔

unread,
Apr 9, 2015, 12:20:36 PM4/9/15
to Dávid Karnok, rxj...@googlegroups.com

On Thu, Apr 9, 2015 at 6:23 AM, Dávid Karnok <akar...@gmail.com> wrote:

You can apply it multiple times but the actual emission will take place on the scheduler which is the closest to the source. All intermediate subscribeOn() are logically no-ops but they have some overhead/side effect:

I think it would be more sensible for subsequent subscribeOn to throw IllegalParameterException or something similar.

-- 
Cédric

Reply all
Reply to author
Forward
0 new messages