[Boost-users] Re: boost::thread::join causes assertion(pthreads)

From: Kevin Wheatley (hxpro_at_[hidden])
Date: 2005-03-22 09:14:29

Vladimir Prus wrote:
> Peter Dimov wrote:
> > Vladimir Prus wrote:
> >> That's the only chance for the problem to be fixed. If I can get it
> >> fail on my Linux box, I can look into it.
> >
> > Isn't this thread about an OS X-specific problem?
> 
> It started this way. However, I'm not sure what system Kevin has in mind OS
> X in mind, or that the problem he has is indeed OS X specific.

There appears to be some confusion here.. so I'll try help. My issue
is that that in general thread::join() has asserts in it that appear
to be triggering (in my case I get them mostly on Windows via
thread_group::join_all) that are hiding/revealing the fact that the
return code from the various platforms supported by Boost.Threads are
being discarded (hopefullt because it prevents the errors from
occuring in theory)

Thorsten appears to have similar concerns on Mac OS X (pthreads) where
the pthread_join() returns EINVAL, now I don't know about Mac OS X but
I belive that indicates the following:

from IRIX (similar wording under Linux):

     [EINVAL]       The thread identified by thread is not joinable
(it is
                    detached).

or perhaps from the Open Group:

    [EINVAL]
        The implementation has detected that the value specified by
thread does not refer to a joinable thread.

On inspection it does not appear that you can create a detached thread
using Boost.Threads on pthreads, so from what Thorsten then says:

<quote>
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.
</quote>

and my reading of pthreads, this suggests join() being called on a
thread more than once or a bug in Mac OS X (Ben Hutchings messages
suggest the same conclusion)

On Windows I'm getting the:

    res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_thread),
INFINITE);
    assert(res == WAIT_OBJECT_0);
    res = CloseHandle(reinterpret_cast<HANDLE>(m_thread));
    assert(res);

res == WAIT_OBJECT_0 assert failing, but I have no idea why because
I'm not told it failed due to the void thread::join().

I guess we both have similar issues but not necessarily for the same
reason. 

Interestingly, the threads return code from thread_proxy() (passed to
pthread_create) is always 0, and is discarded in the pthread_join() so
we are only talking about the thread platforms own return codes.

As far as my bit of code goes I should have been clearer, I thought it
might help with the problem Thorsten had so you can forget it as far
as my problem is concerned...

Kevin

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |