comments on Executor
Sat, 2 Feb 2002 18:59:39 -0500
> i think we need to clarify purposes, perhaps by changing the function names:
> 1. a cancel() which is a method somehow connected to an Executor which cancels
> a started task.
Oh, I think that this is where we are on different wavelengths. You
can cancel a RunnableTask, but the way these are currently designed,
you cannot ask an Executor to do so.
Using the "stronger" interruptible version of Runnable task from my
last mail, when you cancel a task, one of two things happen: (1) If
the task is still in a queue, its cancellation bit set so that its run
method will return immediately when dequeud and executed by some
worker thread. (2) If running, then the worker thread will be
interrupted, die, and be replaced by a new thread if/when needed to
service other tasks. The Executor-object doesn't know anything about
these things except to replace dead worker threads with fresh ones.
This is the best way I know to design thread pools.
> how would you for example perform concurrent reads from 5 channels
> that implement both ReadableByteChannel and InterruptibleChannel,
> using an Executor?
Some slides at
show some of the basic designs options here. I think you'll
see how to go about it from there.
> > So you can use any number of CompositeTasks with the same executor,
> > and cancel each composite independently. Is there something else you
> > need?
> Well, for example, I need a way to wait up to msecs on just the tasks in the CompositeTask.
You can use a java.util.Timer task to send out a
CompositeTask.cancelAll at the timeout period. (It is harmless if the
cancel goes out even though they are all finished, and probably
cheaper to leave it this way rather than cancelling the cancellation.)