[concurrency-interest] Canceling Futures - Callable implementations

Tim Peierls tim at peierls.net
Tue Apr 7 23:41:15 EDT 2009


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

> 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?
>

I don't think so. If your tasks have to call into badly behaved code, then
their cancellation policies are necessarily constrained.

I wouldn't want to standardize cancellation policies for dealing with broken
code, but approaches such as the one Joe suggested are good to have in a
visible spot like this. Note that JCiP has an example of dealing with
nonstandard cancellation policies by overriding FutureTask.cancel; maybe it
should also have briefly mentioned this technique.

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


More information about the Concurrency-interest mailing list