Skip to main content

java.util.Timer.THREAD_TIMEOUT

2 replies [Last post]
eric_arseneau
Offline
Joined: 2004-07-15

I am finally working on getting the source we use in Squawk to the same level as what is found in phoneme Feature trunk. Looking forward to becoming a good phoneme citizen :)

In mainLoop(), we find the following code:
// Wait for queue to become non-empty
// But no more than timeout value.
while (queue.isEmpty() && queue.newTasksMayBeScheduled) {
queue.wait(THREAD_TIMEOUT);
if (queue.isEmpty()) {
break;
}
We made a modification to this code to get rid of the timeout. The reason is that we were getting an interesting side effect due to this code. When Squawk is running, it does not exit until all non-deamon threads have completed. Since the Timer thread is NOT a deamon thread, this means that Squawk will not exit until this thread is done.

Well, with the code in the trunk of phoneme feature, the timeout will cause our VM to exit after the timeout of 30s, if no timers are still running. This does not seem like the correct behavior. We've modified it in our source tree, but like to see what others think and maybe change the phoneme code ?

On phones, this is not much of an issue I guess, since the AMS will only exit based on some kind of external stimulus, or explicit call to destroyApp. In my case, Squawn running on Sun SPOT is an IMP based device and does not really have a sophisticated AMS.

Any thoughts ?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
danila
Offline
Joined: 2006-09-25

Hi Eric,

formally, the existing behavior is valid as it matches the spec for java.util.Timer:

After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur. By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel method.

This allows a MIDP implementation to wait for arbitrarily long interval before it terminates the timer thread.

On the other hand, this wording in the spec allows an implementation to terminate the timer thread as soon as the task queue becomes empty. So I believe the implementation will remain valid if you remove the waiting loop you cited altogether.

The only reason I see in waiting for a timeout is to reduce overhead on new thread creation and collection of dead thread objects. For example, if an application uses the same timer to execute multiple one-time tasks from time to time.

Danila

eric_arseneau
Offline
Joined: 2004-07-15

Apologies for not responding sooner, for some reason I did not get notified of a response and my polling rate seems low :)

I agree the current implementation does conform to the spec.

The issue I have is that this arbitrary amount of time to wait does not cause any noticeable side effects when running on MIDP devices, as the user will be able to explicitly exit his app, or the app will be excited on some external event.

I was about to disagree with the reduction of overhead on creation of new threads and such, but I can see your point. Originally I was going to say that as long as there is a timer on, then the thread will not end. But if developer decides to perform recurring events on their own, then I can see a scenario where the thread would be created for every timer created. This would not be the greatest behavior. But then again, if the developer reschedules beyond the arbitrary timeout, this will also happen.

Ok, will work on what I can do on my end and forget about incorporating this change. Thank you for the feedback.