[concurrency-interest] Canceling Futures - Callable implementations
peter.kovacs.1.0rc at gmail.com
Tue Apr 7 18:43:04 EDT 2009
I am not sure we think of the same sort of problems when talking about
the practically unsafe nature of interruptions. I mean problems such
as the JDBC driver of a leading database vendor getting into error
conditions which are difficult/impossible to recover when interrupted
"unexpectedly". Sure, I cannot fix bugs like this in third-party code,
but can prevent execution from going through it. Sure, foregoing the
potential of short-cutting through the call stack will lead to
suboptimal cancellation techniques, but walking over a mine field is
rarely a reasonable alternative.
Or am I missing something in your comments?
2009/4/7 Tim Peierls <tim at peierls.net>:
> 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).
More information about the Concurrency-interest