2.x: option to fail for using blockingX on the computation scheduler #5020
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds an
RxJavaPlugins
optionfailOnNonBlockingScheduler
that triggers anIllegalStateException
when the user tries to run a blocking method while the execution is on thecomputation()
orsingle()
Scheduler
:It is an optional setting, default off.
The check is done before going into an await method (and a few other types of blocking). Most blocking operators usually poll the status and try to avoid the actual blocking thus this shouldn't affect synchronous sequences that one extracts a value from.
Detection of a blocking-sensitive scheduler's thread is done by checking the current thread's class for implementing the
NonBlockingThread
marker interface (currentlyinternal
).The
RxThreadFactory
has been updated to allow picking a defaultThread
implementation or a custom one for thenewThread()
. Note that since #5002 you can create custom schedulers by providing aThreadFactory
.This works for RxJava's default schedulers but not for
AndroidSchedulers.mainThread()
where similar blocking should be avoided as well. For them, a plugin-callback action would be more suitable.Question is how that callback should behave (throw, return false, should it be always executed or only when the flag is true).My proposed solution is to have a plugin callback
RxJavaPlugins.setOnBeforeBlocking(BooleanSupplier)
that Android users can define the callback for:This callback is only executed if the
failOnNonBlockingScheduler
is set to true.