[concurrency-interest] "Best practice" for ThreadPool creation/run-down

Mark elihusmails at gmail.com
Tue Jan 8 11:06:40 EST 2008

you could add a shutdown hook to the JVM.  Another idea would be to expose a
method for the user to shutdown the API.  This way you are not exposing the
innards of your thread pool.

On Jan 8, 2008 9:57 AM, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:

> Hi,
> I am implementing multi-threaded routines in a Java library to be used
> via Java API. By default, my library "silently" creates the ThreadPool
> it needs. (The library provides API for the user to use whatever
> Executor it wishes to override the default ThreadPool, but the point
> here is the default behavior.) The thing is that the default
> keepAliveTime of the TP is 60 seconds which is (I think) fine. As the
> application is wound down, however, the threads in the pool are
> waiting until their keepAliveTimes expire. That's is fine so far: I
> can provide a handle to shut the TP down without delay at the end of
> the application. But there is this assimmetry which bugs me: I
> silently create something which then needs to be shutdown explicitly
> by the innocent user of the API. Am I the only one to feel
> uncomfortable with this? What is recommended procedure in such cases?
> I've just checked that System.exit(...) doesn't wait for the thread
> pool to wind down. Does this make a difference to my problem? Can I
> rely on the application developer calling System.exit(...)?
> Also, does anyone have it on top their head: how does the existence of
> non-daemon threads affect the termination of an application-context in
> an application container such as Tomcat? (I. e. the case when my
> library is used in a WEB application.)
> Thanks a lot,
> Peter
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

Talent hits a target no one else can hit; Genius hits a target no one else
can see.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080108/a1b535dd/attachment.html 

More information about the Concurrency-interest mailing list