CODEWITHSUNDEEP
rx-java
otal
otal

Reputation: 401

How to use Schedulers.trampoline() inRxJava

Since Schedulers.trampoline() makes the job work on the current thread, I cannot find the difference between the case with Schedulers.trampoline() and the case without Schedulers settings.

Using Schedulers.trampoline():

Observable.from(1, 2, 3)
    .observeOn(Schedulers.trampoline())
    .subscribe(System.out::println)

Not Using Schedulers: 

Observable.from(1, 2, 3)
    .subscribe(System.out::println)

I think that above codes act the same. I really wonder why Schedulers.trampoline() exists in RxJava's API.

In what situation, should I use Schedulers.trampoline()?

Upvotes: 15

Views: 10211

Answers (4)

Alexander Skvortsov
Alexander Skvortsov

Reputation: 2764

There is another usage for Schedulers.trampoline(), please check the following:

println("Current thread: ${Thread.currentThread()}")
Observable.interval(500, TimeUnit.MILLISECONDS, Schedulers.trampoline())
    .subscribe{
        println("$it thread: ${Thread.currentThread()}")
    }
println("This never will be reached")

If the one runs the code on the main thread then the result will be something like this:

Current thread: Thread[main,5,main]
0 thread: Thread[main,5,main]
1 thread: Thread[main,5,main]
2 thread: Thread[main,5,main]
3 thread: Thread[main,5,main]
4 thread: Thread[main,5,main]
5 thread: Thread[main,5,main]
...

And println("This never will be reached") will be reached never.

Upvotes: 4

Hermann Klecker
Hermann Klecker

Reputation: 14068

It comes handy for tests too. In that case you do not use the scheduler directly but inject (or set or hand into your class via constructor) an object (or provider) into your class that holds the scheduler(s) you need. You use this object holding your scheduler in subscribeOn and observeOn. When testing then you inject (or set or hand into) trampoline() instead so your tests all run on the same thread.

Upvotes: 0

Droid Teahouse
Droid Teahouse

Reputation: 1013

Late to the party, but from the docs:

The immediate scheduler is not present in 2.x. It was frequently misused and didn't implement the Scheduler specification correctly anyway; it contained blocking sleep for delayed action and didn't support recursive scheduling at all. Use Schedulers.trampoline() instead.

This would imply your accepted answer may be wrong. See https://medium.com/@I_Love_Coding/rxjava-schedulers-trampoline-use-cases-283f6649cbf that says:

All jobs that subscribe on trampoline() will be queued and executed one by one.

and actually shows an example like

 .subscribeOn(Schedulers.trampoline())

Upvotes: 4

Sergej Isbrecht
Sergej Isbrecht

Reputation: 4002

you would not gain any benefits from using the scheduler in observeOn/ subscribeOn. You would use the Worker from the scheduler to schedule work after work.

Please have a look at the example. I am using RxJava2-RC5

@Test
public void trampoline() throws Exception {
        Scheduler scheduler = Schedulers.trampoline();
        Scheduler.Worker worker = scheduler.createWorker();

        Runnable r1 = () -> {
            System.out.println("Start: r1");
            System.out.println("End: r1");
        };

        Runnable r2 = () -> {
            System.out.println("Start: r2");
            worker.schedule(r1);
            System.out.println("End: r2");
        };

        worker.schedule(r2);
}

Output:

Start: r2 End: r2 Start: r1 End: r1

The trampoline worker comes in handy, if you are scheduling work recursively, because you would not get and StackOverFlow.

The example was rephrased to RxJava from introtorx (http://www.introtorx.com/content/v1.0.10621.0/15_SchedulingAndThreading.html)

Upvotes: 13

Related Questions