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

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


Thinking about it a bit more, one gotcha may be: is the shutdown hook
not called only after after the last non-daemon thread completed? If
so, it could be useless for my purpose.

Thanks
Peter

On Jan 8, 2008 5:32 PM, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> 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
> correct?
>
> 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...)
>
> Thanks,
> Peter
>
>
> 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