river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: A new implementation of TaskManager
Date Tue, 29 Jun 2010 21:35:17 GMT
Thanks. I'll ask TaskManager specific questions in this thread, and 
create a new thread for getting started questions.

The main difficulty I've found so far is the runAfter method in the Task 
interface. As currently defined, it requires the runAfter caller to have 
the tasks in question as the first i elements of a List with efficient 
random access. Although get is indeed marginally faster than an Iterator 
for random access List implementations, it is unfortunately slow and 
inflexible for anything else.

Is this interface something that could be changed, subject to 
corresponding changes in the callers in River, or is it an external 
interface that cannot change?

In general, the design of TaskManager involves a lot of scans, 
insertions, and removals in an ArrayList. Has this caused any 
performance problems, or are the operations sufficiently infrequent and 
the number of tasks small enough for it to not be an issue?


On 6/29/2010 3:50 AM, Peter Firmstone wrote:
> Yes, river-dev is for general development discussion and questions,
> river-commits for svn commits and jira issues which are automatically
> posted. Developers with commit access have a private list for discussing
> potential new committers based on merit etc, but most things are done in
> the open.
> I believe at one stage there was tool com.sun.jini.tool.CheckCodeStyle,
> there is a test in
> trunk/qa/jtreg/com/sun/jini/tool/CheckCodeStyle/test.sh The test gives
> you an idea of the code style required, however the actual tool used for
> checking code is not present in the source.
> Fire away...
> Cheers,
> Peter.
> Patricia Shanahan wrote:
>> I've started taking a look at the code, and have questions ranging from
>> basic building through coding conventions to details of runAfter usage.
>> If I were joining a co-located project I would be arranging to have
>> lunch and an informal chat with one or more of the existing developers.
>> Is this mailing list the lunch room, or is there somewhere more
>> appropriate?
>> Patricia

View raw message