I'm not trying to argue -- but I've seen dead threads (zombies) hang
around for a long time.  Null all possible references in your code
*AFTER* you are done with the thread and do an explicit gc().  I didn't
say that nulling a reference would kill the thread.  It only helps
garbage collection.

The flag (or semaphore) I'm talking about is going to be app specific.
Many times I will start a thread that will run for a while in a loop.
For my apps, I do while(!KILL){} loop then set the KILL flag true when
I want the thread to exit the loop and finish.  And I certainly do
know first hand about deadlock and how hard it is to find where and
why and how to fix.

I understand now that AsyncTask is not a thread -- I didn't before.
So the programming tricks for threads I suggested don't apply here.
A group of managed threads is a whole different deal.

I've never used AsyncTask.  I don't even know if it's in the JDK
because I've never looked for it.  I usually manage my own threads.

Is AsyncTask a part of the Android SDK?

Bob Kerns wrote:
What evidence do you have of this? What exactly do you mean by a
zombie thread?

I've been programming Java since sometime near when it came out --
well over a decade, on various platforms. I've never seen anything I'd
term a zombie thread, nor a thread problem that would be solved by
nulling thread references to null.

I hesitate to say you're incorrect without more specifics, however.

I'm not sure what sort of exit flag you're suggesting. One that
indicates a thread has exited, or one that indicates it should exit?

I'll add that it's certainly possible in Java to write a program that
leaves a thread blocked forever, waiting for something that never
happens. You can also introduce deadlocks -- when two thread each lock
an object, and then try to get a lock on the object locked by the
other.

But this is an issue with ANY thread programming, not Java, and is not
something I'd term zombie threads, nor a Java problem.

Coordinating threads properly is tricky. That's one reason why
AsyncTask is provided, so that you don't have to worry about how to do
it correctly and safely.

BTW, nulling out references to a thread isn't going to make the thread
stop running. In fact, the thread's stack is one of the things that
the GC has to trace through.to find things to keep. The GC cannot just
eliminate the running thread during its run -- and at any point, the
thread's code could ask for the current thread.

Still, I'm not arguing against nulling out the references once you no
longer need them. It documents where you no longer expect to reference
them, and it forces any references after that point to get a
NullPointerException, which will allow you to detect bugs closer to
the point of origin (or worse, detect bugs that might not be noticed).

On Mar 13, 9:44 am, Ken Warner <kwarner...@verizon.net> wrote:
Null out all references to the thread.  Java has a problem
with zombie threads -- this is a java app right?

I can't say exactly how you should do the following but make
sure there is an explicit way to exit each thread. I usually
set a flag to tell the thread to exit.

Those two things -- null all references and setting an explicit
exit flag are the most you can do.

After you null all references to the thread, do an explicit
gc() if that's available.



Gabriel Sim es wrote:
Hello,
Today, while debugging and app that uses AsyncTask to record audio and
update UI I noticed that everytime that an AsyncTask object ends
running (finishes doInBackground() and onPostExecute() or
onCancelled()) it s thread stays alive (running status).
At least for me that should not be the behavior of the class since the
doInBackground task may not stay running forever (as an example the
android manual says that a status bar should be updated by an
asynctask, and it won t last for the whole app running time).
Is there anything I m missing, as a method to destroy it, or should I
just ignore and keep creating threads as I need and the VM will handle
them as it needs resources?
Thank you,
Gabriel Sim es


--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to