On 13/09/2011 5:51 PM, Jing LV wrote: > I've meet a subtle issue with Timer. As we know, every Timer objects > spawn a new thread (which is optionally a daemon thread). On VM > shutdown, there is no way to ensure that the daemon thread terminates
That's exactly the point of daemon threads - they get blown away when the VM terminates. If this is bad then don't use daemon threads. > (cancel() and purge() only clear the queue). This can lead to non-clean > VM shutdown (return non-zero exit code) and has caused problems in some > applications especailly with attach API. Further, there is no way to > determine when all tasks have completed after calling cancel(). Can you please give details of the problems that are encountered and under what circumstances. > This problem was encouraged to occur when the test machine was busy. The > original failure occurs when created& destroyed 15 processes with 1 > JVM's each (via JNI). It seems all versions of JDK has this issue. > I was trying to make a simple testcase but no much progress - though > logically I guess everyone can understand this easily. Current my > workaround is to have some thread to join the Timer thread to wait its > termination - but it seems have some side effect and cause problems. Again please provide details. I'm unclear how join()ing a thread would have problem causing side-effects. Though as a general rule you should never join() a Thread you didn't create/define (otherwise how can you know when it will terminate - the exception being when there is an API that causes the thread to terminate. > A quick idea to resolve the problem completely is to add a new API like > "public void cancel(boolean wait)" to indicate if we will wait for the > Timer threads to be terminated, or add some private methods to help the > VM to do something to terminate the Timer. Without knowing what problems are being encountered it is difficult to judge whether such an API would be of assistance. David Holmes > Any suggestions/comments? Thanks. >
