Kevin Wheatley wrote:
Thorsten Froehlich wrote:
I noticed that when using thread::join and the thread has already completed, at least on Mac OS X using pthreads, pthread_join returns EINVAL, thus triggering the assertion res == 0. Is this intentional or a bug?
I think this is intentional as the same occurs for all 3 platforms Threads supports (personally used on Win32 and Linux). I'd prefer to see the return codes from the various platforms turned into a platform independent error code but I'm not sure what the various possibilities are and if they are small enough to be usefully consolidatable into true platform indepenant codes. You can of cause compile in release mode with the assertions turned off, but its a pain when debugging.
I tried asking about this on the developer list but I guess people are busy (isn't everybody :-) or ignoring me (paranoid!).
Kevin
The following is not strictly Boost specific, but might be helpful: Mac OS X is much more sensitive to thread programming errors than Linux (at least Red Hat 9; there could be other platforms with more compliant and useful pthreads implementations) . We discovered a threading bug in our code only after attemping to port to Mac OS X and getting various thread errors. In each case, we found out that it was a real thread bug in our code (for exmaple, attemping to lock a locked mutex, or unlocking an unlocked mutex) and Linux simply passed through that line of code with no error messages, while OS X crashed immediately with a helpful error message. ACtually, now that I read the man page (pthread_mutex_lock)again, I see that LinuxThreads (and maybe NPTL) uses "fast" mutex kinds by default, which don't check for certain error conditions. In the end, we were able to reproduce the problem using valgrind on Linux IA32. Dave