Using ForkJoinPool.commonPool() in place of RxJava's computation scheduler

Question

I'm currently implementing a small subset of RxJava2's API for a personal project. I have a listener-based API and I started writing the code to wrap my listener and implementing Flowable.create():

public class EventBus {
    private final Flowable<Event> events;

    public EventBus(MyApi api) {
        this.events = Flowable.create(emitter -> {
            Callback listener = new Callback() {
                @Override
                public void onEvent(Event event) {
                    emitter.onNext(event);
                }
            };
            api.addListener(listener);
            // TODO api.removeListener(listener)
        }, BackpressureStrategy.BUFFER);
    }
}.

I ran a quick test and it worked just fine, but I realized it is single threaded. No biggie: it is actually RxJava's design to be single threaded unless specifying a Scheduler.

Per RxJava2's documentation, I decided to chain a Flowable.subscribeOn() call, which I will call with a Scheduler.computation() argument.

So I moved on to implementing Flowable.subscribeOn() and Scheduler.computation(), and this is where I'm trying to wrap my head around: I've seen in various places that Java's ForkJoinPool.commonPool() is recommended to run computation tasks on, But RxJava2 doesn't use it. My main questions would be:

Would this be a good fit for my very basic reactive implementation?
Why did RxJava2 choose to implement its own pool instead of using this one?
Are there any problems with this approach that I should be aware of to make my life easier down the road?

Thanks!

score 2 · Accepted Answer · answered Mar 30 '18 at 08:40

2

Would this be a good fit for my very basic reactive implementation?

Writing adapters to traditional callback apis is somewhat common, assuming there isn't one written already.

Why did RxJava2 choose to implement its own pool instead of using this one?

RxJava always targeted Java 6 and up and ForkJoinPool is Java 7. Note that commonPool sometimes executes work on the caller thread and doesn't go async. We had many unit tests hang on a CI server due to same-pool deadlock.

implementing a small subset of RxJava2's API Are there any problems with this approach that I should be aware of to make my life easier down the road?

What do you mean by that? Are you trying to reimplement RxJava 2, the library, or you are using and applying existing operators in your code?

If the latter and apart from the caveat with commonPool, it depends on what you are trying to interface with.

answered Mar 30 '18 at 08:40

akarnokd

69,132
14
157
192

This is a great starting point, thanks! I am reimplementing the operators that I need (just a bunch for now), but following RxJava2's APIs and semantics in case I want to switch to using the library in the future. It also makes my life easier when trying to understand how everything works and searching for examples online :). Your note on `commonPool` executing work on the current thread is exactly one of those problems I wasn't aware of, thanks a lot! I'll take note of that. – Martín Coll Mar 30 '18 at 14:45
Sounds great! This is how I learned reactive programming 7-8 years ago, with the difference that there were no sources available to Rx.NET, only a handful of videos. I had to experiment through it by writing and running a sequence in C#, then trying to reproduce the same effects in Java. – akarnokd Mar 30 '18 at 15:23
Thanks for being here for people like me, going through similar experiences as you did. And thanks for writing super-clear code to learn from in RxJava :). – Martín Coll Mar 30 '18 at 19:50

Using ForkJoinPool.commonPool() in place of RxJava's computation scheduler

1 Answers1