I have questions about the TaskManager remove(Task) method. Trying to
end work by any means other than run to completion is always a bit tricky.
In the event of a remove call for an active Task, TaskManager issues an
interrupt unless the call is in the task's thread. It also removes the
Task from its bookkeeping.
In the current implementation, removal from the ArrayList immediately
stops the removed task from blocking later tasks that need to runAfter
it. That can let a dependent task start running before the removed task
notices the interrupt. That could be bad if, for example, they share
data that is being protected through the runAfter system.
It will get worse in any performance improved TaskManager. One of the
performance issues is a tendency to use only one thread, regardless of
the number of runnable tasks or the constructor parameters, if there are
a lot of runAfter dependencies. I plan to fix that so that the number of
threads will be in accordance with the constructor parameters.
The other issue is that a task that ignores the interrupt can keep
possession of its thread, indefinitely, despite a remove call. Since we
only create a bounded number of threads, that could effectively kill the
TaskManager. To what extent are TaskManager instances shared by tasks
whose run methods don't have the same trust characteristics?
Patricia
