2.x: option to fail for using blockingX on the computation scheduler#5020
Merged
akarnokd merged 3 commits intoReactiveX:2.xfrom Jan 27, 2017
Merged
2.x: option to fail for using blockingX on the computation scheduler#5020akarnokd merged 3 commits intoReactiveX:2.xfrom
akarnokd merged 3 commits intoReactiveX:2.xfrom
Conversation
Current coverage is 95.67% (diff: 92.45%)@@ 2.x #5020 diff @@
==========================================
Files 609 609
Lines 39379 39427 +48
Methods 0 0
Messages 0 0
Branches 6025 6030 +5
==========================================
+ Hits 37616 37720 +104
+ Misses 764 734 -30
+ Partials 999 973 -26
|
JakeWharton
approved these changes
Jan 27, 2017
| * @since 2.0.5 - experimental | ||
| */ | ||
| @Experimental | ||
| public static void setOnBeforeBlocking(BooleanSupplier handler) { |
Contributor
There was a problem hiding this comment.
Do you have a use case in mind for exposing this API in addition to just the boolean?
Member
Author
There was a problem hiding this comment.
See the updated PR description.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
RxJavaPluginsoptionfailOnNonBlockingSchedulerthat triggers anIllegalStateExceptionwhen 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
NonBlockingThreadmarker interface (currentlyinternal).The
RxThreadFactoryhas been updated to allow picking a defaultThreadimplementation 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
failOnNonBlockingScheduleris set to true.