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

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Tue Jan 8 16:51:20 EST 2008


Thank you, Aaron.

I guess I'll have to read-up on the java.lang.ref package. (I kind of
suspect that this will not work for me, because the thread pool used
is ultimately referenced as a static variable in my library. I'll see
if this is a problem for the PhantomReference scheme.)

Thanks
Peter

On Jan 8, 2008 7:16 PM, Aaron <aaron at mindwidgets.com> wrote:
> Peter,
>    I had a chat with a co-worker about this. If exposing a lifecycle
> interface isn't an option (probably the best route in cases where a
> thread pool is created), a PhantomReference may do what you want. When
> no other references to your pool-holding object exist, you can shutdown
> your thread pool.
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/PhantomReference.html
>
> Thanks,
> Aaron
>
>
>
> Peter Kovacs wrote:
> > 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.
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list