pthread_join stuck in infinite loop

pthread_join stuck in infinite loop

[Julien Ramseier]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Hello,

pthread_join() never returns when calling it on a detached thread.
I would expect it to return EINVAL instead.

Here’s a small test case:

#include <pthread.h>
#include <stdio.h>
#include <errno.h>
#include <unistd.h>

void *world_thd(void *arg) {
	sleep(2);
	return NULL;
}

int main() {
	int ret;
	pthread_t thd;
	pthread_attr_t attr;

	if (pthread_attr_init(&attr))
		return 1;
	if (pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED))
		return 1;
	if (pthread_create(&thd, &attr, world_thd, NULL)) 
		return 1;

	ret = pthread_join(thd, NULL);
	if (ret == EINVAL)
		printf("Thread is not joinable\n");
	else {
		fprintf(stderr, "Failed to join thread: %i\n", ret);
		return 1;
	}

	return 0;
}


--
Julien


[-- Attachment #2: Type: text/html, Size: 4398 bytes --]

Re: pthread_join stuck in infinite loop

[Szabolcs Nagy]

* Julien Ramseier <j.ramseier@gmail.com> [2015-09-20 20:07:28 +0200]:
> pthread_join() never returns when calling it on a detached thread.
> I would expect it to return EINVAL instead.
> 

"If a thread is detached, its thread ID is invalid for use as an
 argument in a call to pthread_detach() or pthread_join()."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_02

"The behavior is undefined if the value specified by the thread
 argument to pthread_join() does not refer to a joinable thread."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html

unfortunately historically ppl believed that detecting detached
state is possible so the rationale for pthread_join still has

"If an implementation detects that the value specified by the
 thread argument to pthread_join() does not refer to a joinable
 thread, it is recommended that the function should fail and
 report an [EINVAL] error."

in particular the glibc man page says EINVAL is correctly
reported in all cases which i dont think is true: there
is a race between the detached thread exiting an join.

Re: pthread_join stuck in infinite loop

[Rich Felker]

On Sun, Sep 20, 2015 at 08:07:28PM +0200, Julien Ramseier wrote:
> Hello,
> 
> pthread_join() never returns when calling it on a detached thread.
> I would expect it to return EINVAL instead.

Calling pthread_join on a detached thread or thread id which is no
longer valid results in undefined behavior. You can't do it. See:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html

  "The behavior is undefined if the value specified by the thread
  argument to pthread_join() does not refer to a joinable thread."

and:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_02

  "The lifetime of a thread ID ends after the thread terminates if it
  was created with the detachstate attribute set to
  PTHREAD_CREATE_DETACHED or if pthread_detach() or pthread_join() has
  been called for that thread. A conforming implementation is free to
  reuse a thread ID after its lifetime has ended. If an application
  attempts to use a thread ID whose lifetime has ended, the behavior
  is undefined.

  If a thread is detached, its thread ID is invalid for use as an
  argument in a call to pthread_detach() or pthread_join()."

Note that it's fundamentally impossible for it to be well-defined for
thread ids whose lifetimes have ended, and it wouldn't really make
sense to have it be defined for still-live detached threads since,
unless you perform additional synchronization to ensure this doesn't
happen, it's possible that a detached thread's exit could race with
your call to pthread_join and cause the id to become invalid.

Rich

Re: pthread_join stuck in infinite loop

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

Am Sonntag, den 20.09.2015, 20:29 +0200 schrieb Szabolcs Nagy:
> * Julien Ramseier <j.ramseier@gmail.com> [2015-09-20 20:07:28 +0200]:
> > pthread_join() never returns when calling it on a detached thread.
> > I would expect it to return EINVAL instead.
> [...]
> in particular the glibc man page says EINVAL is correctly
> reported in all cases which i dont think is true: there
> is a race between the detached thread exiting an join.

Yes, in general this is simply not possible. Otherwise the system
would have to keep track of all threads that had been started by the
process. The idea of detaching a thread (or starting it detached) is
that the system resources that it occupies can be freed as soon as it
exits.

So just don't make the assumption that you may call join in such a
situation. The resources of the thread and the thread ID may even
already have been attributed to a new thread that started after the
first one has exited. So you are not even sure which thread your id is
naming.

Jens


-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: pthread_join stuck in infinite loop

[Julien Ramseier]

Thanks for the explanations. I was misled by the glibc doc.

Julien

> Le 20 sept. 2015 à 20:41, Jens Gustedt <jens.gustedt@inria.fr> a écrit :
> 
> Am Sonntag, den 20.09.2015, 20:29 +0200 schrieb Szabolcs Nagy:
>> * Julien Ramseier <j.ramseier@gmail.com> [2015-09-20 20:07:28 +0200]:
>>> pthread_join() never returns when calling it on a detached thread.
>>> I would expect it to return EINVAL instead.
>> [...]
>> in particular the glibc man page says EINVAL is correctly
>> reported in all cases which i dont think is true: there
>> is a race between the detached thread exiting an join.
> 
> Yes, in general this is simply not possible. Otherwise the system
> would have to keep track of all threads that had been started by the
> process. The idea of detaching a thread (or starting it detached) is
> that the system resources that it occupies can be freed as soon as it
> exits.
> 
> So just don't make the assumption that you may call join in such a
> situation. The resources of the thread and the thread ID may even
> already have been attributed to a new thread that started after the
> first one has exited. So you are not even sure which thread your id is
> naming.
> 
> Jens