-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.x: Make observeOn not let worker.dispose() called prematurely #6167
Conversation
There are 2 x 2 tests that were relying on a race that the previous behavior always allowed. I've updated those tests to avoid the inherent termination-cancel race in them. |
Codecov Report
@@ Coverage Diff @@
## 2.x #6167 +/- ##
============================================
- Coverage 98.23% 98.21% -0.03%
- Complexity 6198 6199 +1
============================================
Files 667 667
Lines 44860 44879 +19
Branches 6214 6214
============================================
+ Hits 44070 44076 +6
- Misses 249 259 +10
- Partials 541 544 +3
Continue to review full report at Codecov.
|
For me the situation in #6146 is an anti-pattern (having more than one blocking subscribe in a Flowable chain) so I hope to avoid it entirely. Having said that I understand that this PR helps the situation described in #6146. @akarnokd Would you say the window of opportunity for unwanted |
It is definitely narrowed but I can't prove it is eliminated or that we aren't back to state where excess io creation happens. It is better to confine blocking to its own io scheduler via subscribeOn so that such onComplete blocking doesn't elongate the scheduler's life and also doesn't keep the previous operator's stack. |
Some operators may call
dispose()
/cancel
fromonError
/onComplete
which could trigger a permature call toworker.dispose()
that was about to happen anyway. This PR prevents this by moving the operator into its disposed/cancelled state before signaling the terminal event, thus a downstreamcancel()
/dispose()
call won't trigger this premature cleanup.Such premature cleanups may cause unwanted
Schedulers.io()
reuse in some scenarios.Related: #6146