Thread Interruption on Unsubscribe

[benjchristensen]

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).

• Computation Scheduler gets interrupted thousands of times per second? #1913 Computation Scheduler gets interrupted thousands of times per second?
• Scheduled action no interrupt #1898 Scheduled action no interrupt
• Fix Take Early Unsubscription Causing Interrupts #1832 Fix Take Early Unsubscription Causing Interrupts
• "Interrupted while waiting for subscription to complete." in 1.0.0-rc8 #1804 "Interrupted while waiting for subscription to complete." in 1.0.0-rc8

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.

[daschl]

@benjchristensen makes total sense. I'm not so into the details, maybe we can only do the interruption on the IO scheduler? especially not on the computation one.

[akarnokd]

The developers of the JDK threadpool couldn't decide it either so they went for providing the option to the programmer. Either we don't do interrupts on the computation scheduler, but do it everywhere else; or we extend the API and inject an interruptible flag all around.

Two clarifications: ScheduledAction has its own Future wrapper; ScheduledAction wraps an Action0 and the ScheduledAction itself is not accessible inside this Action0 so it can't act as a cancellation token nor can be manipulated to gain access to the Future it holds to issue an cancel(true); one would need to exfiltrate the worker thread but then it becomes dangerous to call interrupt on it.

[akarnokd]

I have a ScheduledAction enhancements that will support customization of the interrupt behavior. See #2592.

[benjchristensen]

Resolved in #2579

[vinc3m1]

Following #2579 to #2592 to #2761 to #2772, it doesn't look like this is actually resolved, is it @akarnokd?

[akarnokd]

None of the customizations made it and it seems Hystrix solved it internally. There were a few changes made to ScheduledAction so it doesn't call cancel(true) when cancelling from the same thread.