Dhanji R. Prasanna
dhanji at gmail.com
Sun Jul 9 06:32:14 EDT 2006
On 7/9/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> On 7/9/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> > I must be missing something. If you want to submit the same task
> > times then submit the same task multiple times. If you want a task to
> > then either code it so it repeats, or resubmits itself or use a periodic
> > task if there is a repeat interval.
> The problem with resubmitting a task is that you can't increase the
> size of the pool.
Sure you can. setCorePoolSize() and setMaximumPoolSize() can be called any
time after construction, along with prestartCoreThread() to force the pool
to change size dynamically.
David's suggestion makes a lot of sense; simply let your queue feed the same
task over and over.
I would also say that setting a starting corePoolSize of 0 is pointless, and
probably confusing to a maintainer. The ThreadPoolExecutor does not create
the first thread until it is needed anyway, so you have not gained anything
with a starting size of 0. If you want your executor to drop to 0 threads at
a mature point in its lifecycle, just release it to the gc and create a new
one when needed. Otherwise I dont see the point of (effectively) using
ThreadPoolExecutor as a state machine for your app.
The problem with a tasks that loops is that the executing thread in
> the executor is 'lost' forever.
But there is only ever one task that he wants to repeat, if I understood
correctly, so what is the problem with running it in the same thread
Repeat = sequential, resubmit/multiple submit = concurrent. Either way the
problem does not require a special delegating executor (unless this is
simply an abstraction facade for your app).
Maybe Im not seeing the issue...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest