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 |