9

How can one know if a pthread died?

Is there a way to check a pthreads status?

some_id
  • 29,466
  • 62
  • 182
  • 304
  • 2
    It should be noted that threads can't just "die". The only ways a thread can be terminated without the whole process being terminated are: (1) returning from its start function, (2) calling `pthread_exit`, (3) calling a function which is a cancellation point while cancellation is not blocked and `pthread_cancel` has been called on it, or (4) being the target of `pthread_canel` while asynchronous cancellation is in effect. – R.. GitHub STOP HELPING ICE Jun 14 '11 at 04:41

3 Answers3

10
if(pthread_kill(the_thread, 0) == 0)
{
    /* still running */
}

See: pthread_kill

Note: there is an inherent risk to using pthread_kill() to test if a thread is still running. See this post for an explanation: How do I determine if a pthread is alive?

Community
  • 1
  • 1
Damon
  • 67,688
  • 20
  • 135
  • 185
  • Will this kill the thread first, or attempt to do so. Or will it just check it? thanks – some_id Apr 23 '11 at 13:52
  • From above link: _"As in kill(), if sig is zero, error checking shall be performed but no signal shall actually be sent"_. Which means no, it will not kill the thread. It will just tell you whether it's still there. – Damon Apr 23 '11 at 13:53
  • @Damon: Btw, is this 'the_thread' the name of the thread, the actual thread? or is it the return value of the thread? e.g. gpsNavigationThreadResult = pthread_create(&gpsNavigationThread, NULL, setupgpsnavigation, (void*) message3); – some_id Apr 23 '11 at 15:57
  • It is the `pthread_t` that you got from `pthread_create` (i.e. the thread id). – Damon Apr 23 '11 at 16:04
  • 2
    This code is only valid if `the_thread` is joinable and not-yet-joined. If it was already joined or if it was detached, then any use of its thread id, including with `pthread_kill`, after its lifetime results in *very dangerous* undefined behavior. – R.. GitHub STOP HELPING ICE Jun 14 '11 at 04:37
  • Can you provide a source for this claim? According to POSIX, this is an idiom explicitly for verifying a thread id's validity, and the implementation is required to cope with it and perform proper error checking. It is explicitly required to work with any thread ids, even entirely invalid ones. There are no "cave joined" paragraphs that I'm aware of anywhere in either POSIX, nor in SUN/Oracle's man pages, nor in the Linux kernel manpages. – Damon Jun 14 '11 at 07:30
  • @Damon A conforming implementation is free to reuse a thread ID. A thread ID can also be a pointer to a structure that is freed when the thread is joined. See [XSH 2.9.2](http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html) which says, "*If an application attempts to use a thread ID whose lifetime has ended, the behavior is undefined.*" Do you have a cite for your claim that POSIX says this is an idiom for verifying a thread ID's validity? The [pthread_kill](http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html) has no "shall fail" section for this. – David Schwartz Sep 26 '16 at 11:36
4

I want to add to the discussion the fact that a thread can just die in another case that is not mentioned here in the case of a signal such as SIGPIPE when it is not handled by the hosting process or the thread it self and in situations when such a signal can arise

cod3r43v3r
  • 41
  • 1
4

If you don't need to write a portable application and can use GNU extensions, you can use pthread_tryjoin_np. I believe there isn't another way to do it, except for setting up communication between two threads (e.g. using a global mutex which is hold by a thread as long as it is alive).

evnu
  • 6,450
  • 2
  • 27
  • 38