[concurrency-interest] Whats up with the ThreadPoolExecutor?
jbloch at gmail.com
Tue Aug 23 01:37:28 EDT 2005
It was not an accident that you can't reuse a finished timer task. It
was a conscious design decision, based the principal that one should
minimize mutability (keep the state space of a object as simple as
possible). In fact, I use it as an example of good API design in my
API design talk. I would be very, very surprised if you could come up
with a realistic example of a program whose performance is noticeably
improved by reusing timer tasks.
On 8/22/05, Gregg Wonderly <gergg at cox.net> wrote:
> Doug Lea wrote:
> > David Holmes wrote:
> >> There is an easy fix that Dawid can hopefully get into the backport in
> >> the
> >> very near future:
> > And the fix for the java.util.concurrent version will with some luck be
> > in Mustang.
> > While we never expected anyone to reuse Runnable tasks
> > in this way, (and in general, it is not a good idea)
> > the specs did not say you cannot, so it is indeed a bug.
> I've recently made changes to Timer to allow TimerTasks to be reused so that a TimerTask can reschedule the same object
> into the future without a lot of garbage being generated for fast cycling tasks with odd repeating intervals. I think
> it makes a lot of sense to try and work towards reducing garbage generation by not requiring new objects. There are, of
> course some interesting issues, such as this one...
> Gregg Wonderly
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest