ExecutorScheduler Concurrency and Performance Issues

[benjchristensen]

The ExecutorScheduler, or at least the backing implementation of Schedulers.threadPoolForComputation() is needed because:

1. It allows concurrent execution if used in a pattern other than sequential recursion. In other words, it doesn't protect against misuse: Fix Scheduler Memory Leaks #712 (comment)

2. Performance is very bad when doing recursion: Recursion on ExecutorService with >1 Thread is Slow #711

[benjchristensen]

Removed ExecutorScheduler and replaced with ComputationScheduler that has a pool of event loops: #1048

[aij]

I seem to be failing to understand how ComputationScheduler is a replacement for ExecutorScheduler. I was using ExecutorScheduler because I needed certain code to run in a certain thread. Specifically, I was using .observeOn() so the observer would be executed on the Android main thread.

I'd also be perfectly happy with a scheduler that wraps a scala.concurrent.ExecutionContext instead, as that would be more idiomatic for Scala. Is there a way to do either with ComputationScheduler?

[samueltardieu]

I used it to bound the number of IO requests in progress at the same time to avoid saturating the memory of the receiver on Android. I guess I will have to find another way.

[benjchristensen]

I seem to be failing to understand how ComputationScheduler is a replacement for ExecutorScheduler

It's not a direct replacement. The ExecutorScheduler had significant problems as this issue discusses.

Specifically, I was using .observeOn() so the observer would be executed on the Android main thread.

You should use the AndroidScheduler: https://github.com/Netflix/RxJava/tree/master/rxjava-contrib/rxjava-android#observing-on-arbitrary-threads

as that would be more idiomatic for Scala

That should be done as part of rxjava-scala: https://github.com/Netflix/RxJava/tree/master/language-adaptors/rxjava-scala

I used it to bound the number of IO requests in progress at the same time

This is a valid use case (at Netflix we use Hystrix for that server-side, but that's not helpful for Android).

I'm totally okay with ExecutorScheduler coming back as long as it complies with the contract, which it never has. It is not obvious how to make it work.

The concurrent throttling case can be solved in other ways, including a Scheduler implementation that has a bounded number of threads, but that correctly use event loops on top of each thread. I know @akarnokd was experimenting with a fixed-side event loop pool that could be used for this.

If that was adopted into the core library, it would probably be something like Schedulers.fixedPool(int num), but the problem with that is it's a factory that produces a new pool every time, so users would have to make sure to create it and store a reference to it, otherwise it would not work. This is quite different from how the other Schedulers are used, where the factory methods are invoked every time such as Schedulers.io(), Schedulers.computation() and Schedulers.newThread().

What do you all think should be done?

[dvogel]

I would like to see the ExecutorScheduler come back without the default thread pool concurrency. ExecutorScheduler was the simplest way to delegate scheduling to the glib event loop:

public class GlibExecutor implements Executor {
    @Override
    public void execute(@NotNull final Runnable runnable) {
        Glib.idleAdd(new Handler() {
            public boolean run() {
                runnable.run();
                return false;
            }
        });
    }
}

It looks like I now have to subclass rx.Scheduler directly. That seems straight-forward enough, but the ExecutorScheduler was very nice here.