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

Aaron aaron at mindwidgets.com
Tue Jan 8 13:16:38 EST 2008


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