Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <718FD117-B781-4ADA-A714-8C07392134B0@gmail.com>
Date: Mon, 21 Sep 2015 11:00:48 +0200
From: Julien Ramseier <j.ramseier@...il.com>
To: musl@...ts.openwall.com
Subject: Re: pthread_join stuck in infinite loop

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

Julien

> Le 20 sept. 2015 à 20:41, Jens Gustedt <jens.gustedt@...ia.fr> a écrit :
> 
> Am Sonntag, den 20.09.2015, 20:29 +0200 schrieb Szabolcs Nagy:
>> * Julien Ramseier <j.ramseier@...il.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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.