A few issues recently have been related to Thread interruption and brings into question why we interrupt the thread when we unsubscribe a scheduled action (via a Scheduler).
The code that causes this is from https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/subscriptions/Subscriptions.java#L102 that wraps a Subscription around a Future. This in turn is used by ScheduledAction which is used when scheduling work via a Scheduler.
Issue #1898 is working to not cause an interrupt after successful termination, but I want to question why we ever interrupt as default behavior.
I don't think much thought went into choosing to call cancel(true) instead of cancel(false) and I'd like to discuss changing this to not interrupt.
The implication of interrupting are difficult to manage well and add a lot of complexity.
The only time interrupting seems wanted is if unsubscribing early to a ScheduledAction doing blocking IO. Otherwise the Subscription itself is the cancellation token that work should be checking (most code doesn't properly use Thread.isInterrupted() anyways so it rarely helps).
If an Observable is doing blocking IO it seems it should opt itself into doing Thread interruption. Perhaps we should figure out an idiomatic approach to that for opting into that behavior without requiring interruption all the time.
A few issues recently have been related to Thread interruption and brings into question why we interrupt the thread when we unsubscribe a scheduled action (via a
Scheduler).The code that causes this is from https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/subscriptions/Subscriptions.java#L102 that wraps a
Subscriptionaround aFuture. This in turn is used byScheduledActionwhich is used when scheduling work via aScheduler.Issue #1898 is working to not cause an interrupt after successful termination, but I want to question why we ever interrupt as default behavior.
I don't think much thought went into choosing to call
cancel(true)instead ofcancel(false)and I'd like to discuss changing this to not interrupt.The implication of interrupting are difficult to manage well and add a lot of complexity.
The only time interrupting seems wanted is if unsubscribing early to a
ScheduledActiondoing blocking IO. Otherwise theSubscriptionitself is the cancellation token that work should be checking (most code doesn't properly useThread.isInterrupted()anyways so it rarely helps).If an
Observableis doing blocking IO it seems it should opt itself into doing Thread interruption. Perhaps we should figure out an idiomatic approach to that for opting into that behavior without requiring interruption all the time.