[concurrency-interest] Canceling Futures - Callable implementations

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 7 13:10:49 EDT 2009


Callable was designed to be useful stand-alone, like Runnable.  Because of
this, Callable has no more knowledge of its Future (if associated) than
Runnable has of its Thread, and therein lies the rub when one is trying to
write a Callable that knows the state of its Future.

A better "Callable" for the purpose of detecting cancellation might have

  public interface MyCallable<V> {
      V call(Future task) throws Exception;

Then you could write "callables" of the form:

  MyCallable<Integer> mc = new MyCallable<Integer>() {
      public Integer call(Future task) {
          while (!task.isCancelled()) {
              Thread.yield(); // Please!!
          return 0;

Below is a Task class that uses these instead:

class MyTask<V> implements Future<V>, Runnable {

    protected final FutureTask<V> task;

    public MyTask(final MyCallable<V> mc) {
        task = new FutureTask<V>(new Callable<V>() {
            public V call() throws Exception {
                return mc.call(task);

    /* Runnable implementation. */

    public void run() {

    /* Future implementation. */

    public boolean cancel(boolean mayInterruptIfRunning) {
        return task.cancel(mayInterruptIfRunning);

    public boolean isCancelled() {
        return task.isCancelled();

    public boolean isDone() {
        return task.isDone();

    public V get() throws InterruptedException, ExecutionException {
        return task.get();

    public V get(long timeout, TimeUnit unit)
        throws InterruptedException, ExecutionException, TimeoutException {
        return task.get(timeout, unit);

This internal FutureTask construction is also found in SwingWorker, by the


2009/4/7 Péter Kovács

> Hi,
> How will a Callable implementation know that the corresponding Future
> has been canceled?
> 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.
> Is there anything else in place for this purpose? If there is not,
> wouldn't it be reasonable to provide a "useful" default implementation
> of Callable -- along the lines of FutureTask being an implementation
> of Future?
> Thanks
> Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090407/775df810/attachment.html>

More information about the Concurrency-interest mailing list