Should RxRingBuffer's validator really be on the computation scheduler? #3923
Description
I just helped debug an issue where some Android robolectric tests timed out after upgrading from 1.1.1 to 1.1.5 due to ef1d418
As it turned out, they were replacing the computation scheduler with immediate via RxJavaPlugins. The new commit caused RxRingBuffer.SIZE to load the RxRingBuffer class in any call to observeOn, which in turn created its ObjectPools, which in turn ran their start() which sets up a periodic scheduling on the computation thread. This caused the tests to hang indefinitely because of the repeated SleepingActions triggered by the validation tasks.
So, since RxRingBuffer can be loaded in various places by Rx internally, that seems to make it a lot more difficult to reliably replace the computation scheduler, particularly with immediate. I recommended against the immediate override in this case, but using a test scheduler wasn't really helping in this scenario either, although I am unfamiliar with that codebase and didn't have time to dive too deep into why. Short term fix for this particular case was to call observeOn with a size constant to sidestep the RxRingBuffer load in these tests, until we can clean up the underlying scheduler plugin overrides. However, I'm wondering if maybe internal scheduling things like this should have their own scheduler? Maybe an internal computation scheduler that could be an additional override in the schedulers hook. That would allow them to run unhindered in most cases despite computation being overridden, but in extreme cases they could be overridden as well.