Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C43523E.7050706@zeus.net.au>
Date: Mon, 19 Jul 2010 05:13:02 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: TaskManager requirements
References: <4C427155.9000801@acm.org>
In-Reply-To: <4C427155.9000801@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Patricia Shanahan wrote:
> 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.

Perhaps a hashmap might be used to store tasks that are pending removal, 
so they can be left on the queue until the removed task has been 
interrupted?

>
> 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?

Currently TaskManager is only used internally, so the trust should be 
the same between tasks, although I like the idea of a singleton 
TaskManager and did mention it earlier, that doesn't suit the current 
implementation.  We could put an AccessController permission check in 
TaskManager before a task is placed into the queue?

>
> Patricia
>