[concurrency-interest] Canceling Futures - Callable implementations

Tim Peierls tim at peierls.net
Tue Apr 7 17:40:47 EDT 2009

2009/4/7 Péter Kovács <peter.kovacs.1.0rc at gmail.com>

> One mechanism I am aware of is thread interruption, but practice shows
> that relying on this mechanism is highly unsafe. For interruption
> checks to work safely, everyone up the call stack would have to
> observe the related protocol, which is rarely the case.

In defense of interruption:

If you execute your Callables in a ThreadPoolExecutor, the interrupt status
is managed carefully so that an interrupt-based cancellation of one task
won't affect other tasks in the same pool thread.

Code that silently swallows the interrupt on an InterruptedException is
broken even if you aren't relying on interruption for cancellation, so I
don't think it's fair to say that "relying on this mechanism is highly
unsafe". Relying on broken code is unsafe.

Regardless of the protocol you adopt for cancellation, everyone up the call
stack has to be aware of the protocol in order to be responsive to
cancellation requests. And testing interrupt status can be done anywhere in
the call stack without passing or setting special context. That's not the
case, for example, with the technique Joe illustrated, where all code
reachable from MyCallable needs to be able to get the task cancellation
handle (the Future). Joe's technique is useful, especially when you can't be
sure your Callable will run in a protected environment like
ThreadPoolExecutor, but I'm not convinced it needs to be standardized
(doesn't sound like Joe is, either).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090407/eae21eb8/attachment-0001.html>

More information about the Concurrency-interest mailing list