[concurrency-interest] ScheduledThreadPoolExecutor and shutdown permission check.

Gregg Wonderly gregg at cytetech.com
Wed Apr 30 16:09:30 EDT 2008

Endre Stølsvik wrote:
> Gregg Wonderly wrote:
>> Ben Manes wrote:
>>> Yes, but my point was that there may not be a need for an explicit 
>>> shutdown and an implicit one when the applet was stopped would solve 
>>> most use-cases.
>> The STPE is used in a class which has hundreds of instances created 
>> and destroyed over the life of the applet.
> While I agree to the problem you're describing (it is downright silly 
> that threads you been allowed to create and use shouldn't be 
> *controllable* by you too - I mean, what you're really asking is to have 
> the threads you've (implicitly) created simply exit their run() 
> methods), I find this specific usage you describe here somewhat strange: 
> Why not have one pool that these instances share? I thought a big point 
> of a threadpool is that thread creation and stopping is rather expensive.

The basic problem is that this class is used when the user selects something in 
the GUI, to perform work for that selection.  When they select something new, I 
need to shut that down and create another instance.  The class really is 
standalone.  If I passed in the STPE instance, or had it use a static instance, 
then I could leave that one running.  I really dislike having all that linkage 
between standalone objects and the users of them.  The thread pool use is not a 
publicly describable behavior of the class.  It just does the work and gives the 
results and knowing that the STPE is being used, is "under the covers" knowledge.

I guess I'll just have to do something different for this case...

Gregg Wonderly

More information about the Concurrency-interest mailing list