When an thread is cancelled or exits, when does it go into the DEAD state
versus just going away altogether. DEAD is described as ending and waiting
for a join by another thread… Is it a problem in having a DEAD thread and
did we do something in our thread or the thread that created it that caused
it to go to the DEAD state instead of ending completely?
Jay Witherspoon <spoon@scubadiving.com> wrote:
When an thread is cancelled or exits, when does it go into the DEAD state
versus just going away altogether. DEAD is described as ending and waiting
for a join by another thread… Is it a problem in having a DEAD thread and
did we do something in our thread or the thread that created it that caused
it to go to the DEAD state instead of ending completely?
The default is that a thread will go to a DEAD state until another
thread does a pthread_join() on it. (This is the equivalent of a
zombie process, when you haven’t done a wait() or waitpid() to get
its exit notification.)
If you don’t want to join your dead threads, pthread_detach( thread_id)
after creating, or pthread_detach(pthread_self) in the thread will set
them to not do this.
Or, before you create it:
pthread_attr_setdetachstate( &thread_attr, PTHREAD_CREATE_DETACHED );
then pass the thread_attr attribute to the pthread_create() call.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Jay Witherspoon <spoon@scubadiving.com> wrote:
Is it a problem in having a DEAD thread
Yes and no – it is a “normal” and expected state for a thread – but
it does consume an entry in the thread table, and a small amount of
associated resources to maintain this entry for dead threads.
So, it is better to clean them up, or not have them die (as I
mentioned how in previous post.)
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.