2.x: add subscribeOn overload to avoid same-pool deadlock with create #5386
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 overload to
subscribeOn
that exposes the existing feature to optionally request on the same scheduler where the subscription happened. This is necessary to avoid same-pool deadlock when the upstream containscreate
logic that blocks the emission thread, preventing any scheduled request to get through and leading to excess buffering or dropping data excessively. By not scheduling the request, it can directly update the emitter's request tracking and let the emitter continue.Formerly, the existing
subscribeOn
automatically disabled scheduling the requests if the immediate upstream was aFlowableCreate
. However, if there were operators betweencreate
andsubscribeOn
(as often happening on Android with composing the schedulers at the end of the chain), thesubscribeOn
operator run in scheduled request mode by default.This change allows specifying this behavior through the new overload and thus distance between the
create
andsubscribeOn
operators no longer matters.(Note that 1.x already has this overload.)