[concurrency-interest]Re: comments on Executor

Doug Lea dl@cs.oswego.edu
Sun, 3 Feb 2002 08:10:33 -0500

Mark wrote:

> In the lines of your sample code:
>   public synchronized void cancel() {
>     if (!isDone()) return;
> that "!" shouldn't be there, right?

Yes, sorry.

> Also, how does the Executor know not to interrupt the thread if the cancel() has done so?

PooledExecutor interrupts worker threads, it doesn't know anything
about the tasks they run. PooledExecutor.interruptAll and related
shutdown methods just invokes interrupt on all worker threads. So it
is indeed possible for a task to be cancelled from inside user code,
but before it has completely terminated, for the pool to be shut down.
User task code must deal sensibly with receiving multiple
interruptions.  But this is is no different than writing cancellation
code in general: you must always be prepared to be interrupted in the
midst of dealing with another interruption.  If your cancellation
strategy is "get out quick after minimal cleanup", all is usually well.

> wouldn't
> it be anti-social for cancel() to kill itself 

You can do all sorts of anti-social things with interruption/cancellation!

> What i want is something that says "wait at most msecs for everything to be done; if they
> all finish sooner, return as soon as that is true; if some are not done at msecs, then
> cancel/interrupt them and return".

You can build a custom CompositeRunnableTask that does all this and more.
I'm not at the moment convinced that there's a more general version
that would be worth officially supporting.