Would this be roughly equivalent to:
Executors.newCachedThreadPool()?
The doc says:
"Creates a thread pool that creates new threads as needed, but will
reuse previously constructed threads when they are available."
That factory creates a ThreadPoolExecutor with a core size of 0, maximum
size of Integer.MAX_VALUE, and it kills idle threads after 60 seconds.
We can construct our own ThreadPoolExecutor if we need finer control of
those parameters.
I may be missing some subtle detail, though.
jamesG
On 6/4/2010 4:11 PM, Gregg Wonderly wrote:
I'd have to say no for the existing Executor implementations in the JDK.
The concurrency utilities related to Executor in the JDK are tailored
for, and specifically limited to applications where you have unrelated
tasks that need to be throttled amongst a limited set of threads.
River's TaskManager will always create more threads, but will prune
those threads after they sit idle for too long. We need this behavior to
keep away from distributed deadlock which can occur anytime another
remote operation might be the only way that progress can happen in the
overall processing of a distributed application.
Be very careful where you use j.u.c ThreadPoolExecutor et.al, because of
their design. It would be possible to use an appropriate Executor
implementation, but it would have to behave like TaskManager and always
create a new thread for new work, when no idle threads are available.
Gregg Wonderly
Dennis Reedy wrote:
Hi Gregg,
Does it make sense to move to concurrency utilities and move away from
TaskManager altogether?
Dennis
On Jun 4, 2010, at 1100AM, Gregg Wonderly wrote:
The TaskManager class has a subclass of Thread that it uses to run
tasks. The problem with subclassing Thread, is that there is a lock
that is used in Thread to see if some methods are overridden so that
security can be maintained. So, in an environment where Thread is
used with a SecurityManager, it is better to use a Runnable to
encapsulate the custom code, instead of a Thread.
The TaskThread class should be a Runnable instead of a Thread, and
then there are just 3 other places where it is referenced that need
some adjustment. The thread that is running inside of the runnable
needs to be put into a per instance variable for one place where
interrupt processing is handled.
Gregg Wonderly
