[concurrency-interest] "Best practice" for ThreadPool creation/run-down
aaron at mindwidgets.com
Tue Jan 8 13:16:38 EST 2008
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.
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.
> 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
>> 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:
>>>> 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,
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at altair.cs.oswego.edu
>>> 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
More information about the Concurrency-interest