Future cancel(true) vs. channels/streams

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Future cancel(true) vs. channels/streams

Andrew Lentvorski
I was looking at converting some of my Runnable-based code over to
Callable-based code.  However, I have some concerns about applying
cancel() to a thread which is already running.

cancel(false) doesn't seem to do anything once the thread is running
cancel(true) seems to cause an InterruptedException

That's okay, but ...

If I'm actually in an I/O operation for a Channel/Stream, wouldn't that
InterruptedException cause my Channel/Stream to close?

If that is the case, I can't really use cancel(true) on anything which
might have a persistent I/O state.

It would be nice if cancel(false) set some sort of flag which could then
be monitored inside the Callable.  Is this possible?  Did I miss
something obvious?

Otherwise, I have to have this kind of idiom:

public class CallableSkeleton implements Callable<Foo> {
        AtomicBoolean flgStopRequested = new AtomicBoolean(false);
       
        public boolean isStopRequested() {
                return this.flgStopRequested.get();
        }

        public void requestStop() {
                this.flgStopRequested.set(true);
        }
}

which kind of defeats the whole point of using cancel in the first
place.  Or, worse, requires that I do both:

callableFuture.cancel(false);
callable.requestStop();

to make *sure* that I get all of the termination cases (and has to be in
that order or you get possible race conditions).

Am I wrong?  Did I miss something obvious?

How should I go about cancelling a Callable which might have persistent
I/O state?

-a


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Future cancel(true) vs. channels/streams

Dawid Kurzyniec
Andrew Lentvorski wrote:

> I was looking at converting some of my Runnable-based code over to
> Callable-based code.  However, I have some concerns about applying
> cancel() to a thread which is already running.
>
> cancel(false) doesn't seem to do anything once the thread is running
> cancel(true) seems to cause an InterruptedException
>
> That's okay, but ...
>
> If I'm actually in an I/O operation for a Channel/Stream, wouldn't
> that InterruptedException cause my Channel/Stream to close?
>
> If that is the case, I can't really use cancel(true) on anything which
> might have a persistent I/O state.
>
> It would be nice if cancel(false) set some sort of flag which could
> then be monitored inside the Callable.  Is this possible?  Did I miss
> something obvious?


It seems to me that you can achieve what you want by extending
FutureTask and overriding done() like this:

class MyTask extends FutureTask {
  protected void done() {
    if (isCancelled()) {
      // do the I/O cleanup, and close whatever needs to be closed
    }
  }
}

then use executor.execute(myTask), and myTask.cancel(false).
Cancellation will set the state to CANCELLED and invoke done(), where
you then do your cleanup. (Thread does NOT get interrupted).

Regards,
Dawid


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest