Is there any way to interrupt a Future without cancelling it?
boolean cancel (boolean mayInterruptIfRunning)
Attempts to cancel execution of this task. This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason. If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task.
To capture the interrupt, we have to properly catch the Interrupted Exception or check the isInterrupted() method within the Runnable / Callable method.
But there is no way to interrupt a running Future using the Future interface
Since all the threads are in the Executor Service pool, no one can do thread.interrupt(). Is that why it has been assumed that any interrupt will come only when a Future is cancelled or a Thread Pool is terminating?
I am trying to understand why there is not a interrupt method in the Future interface. Any help will be greatly appreciated
The reason is because of the difference in the abstraction that is a Future and the concrete execution in a thread. We cannot say if a future is tied to a single thread or multiple thread. A future may start new threads, start new futures, etc.
Consider these abstractions as interactions between the client code and the executor of the futures. Conceptually it makes sense to say "cancel this task I have asked you to do" because it was your task to cancel. I may be busy working on it, or I may not have started it yet, or it may be finished but that's all fine, I will cancel it if you want me to. So that's why we have a cancel method.
On the other hand, it does not make as much sense to say "interrupt your task". Because of the decoupling between the result of the action (the Future) and the execution model (say an Executor), the client does not have knowledge of what actions are being taken to fulfil the task. How then can the client be expected to know when an interrupt is appropriate, required, or even supported.