Ben Hutchings wrote:
I'm not sure whether you mean that the thread has exited or that it has also been joined.
The thread ended normally as the thread's function returned. There does not appear to be any way to detect this in boost::thread.
EINVAL, thus triggering the assertion res == 0. Is this intentional or a bug?
Which part of this behaviour are you questioning?
That when I try to join a thread that is no longer running, which cannot be reliably determined by the given thread class interface (well, it cannot at all in fact), then getting an assertion upon try to join that thread is a bug.
The reasons why pthread_join may fail all represent bugs rather than unpredictable errors, hence the assertion.
Sorry, this is incorrect, see below.
Joining a thread makes the thread object an empty shell which has no further use. Detaching a thread also makes it non-joinable and makes the thread object almost useless. If your program attempts to join a non-joinable thread, that's the bug. Otherwise, it is conceivable that you have found a bug in MacOS X or in Boost.Threads, but I'd be surprised.
I am perfectly aware what happens in the code. My code is certainly correct and doing nothing invalid at all - the problem is with boost thread behavior or interface (well, lack of it) to prevent the assertion, which would only be possible by checking if a thread terminated already, and checking for this in a reliable manner. Boost threads does not provide that facility. Thus, an assertion is incorrect at that point in the boost thread join code. Thorsten