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

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Tue Jan 8 11:32:25 EST 2008

Thanks for the tips!

I had thought the shutdown hook is called only for Control-C/SIGINT et
al. based on the description of the -Xrs swith of java: "The JVM
watches for console control events to implement shutdown hooks for
abnormal JVM termination." But now I realize that the console control
events may be listened to only to detect abnormal termination and the
shutdown hook is also called for normal program termination -- on the
main function returning or the System.exit() being called. Is this

Shutting down the entire API is also an interesting approach, but the
shutdown hook appears to be the less intrusive on the user of the two.
(The API shutdown is probably a more natural fit for device control
APIs or similar, which is not my case...)


On Jan 8, 2008 5:06 PM, Mark <elihusmails at gmail.com> wrote:
> 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.

More information about the Concurrency-interest mailing list