Ben Hutchings wrote:
Kevin Wheatley wrote:
To me the most obvious thing missing is something like:
void thread::join() { assert(m_joinable); int res = 0;
rest of function....
Yes, that could make the cause of errors clearer and would do a much better job of detecting them than the assertion about the result of the system return value. The ID or handle value in a non-joinable thread object could be reused by the time of the erroneous join, so that the error would not be detected by the system join function.
as a note, if this were to happen, it would suggest that a mutex is needed for the duration of the thread::join() function to avoid what then becomes a race condition relating to the m_joinable boolean under the condition that multiple joins() are called by different threads at the same time. This of course depends on the outcome of the question: is it an error to do so? In all the programs I have written I've had a single thread have the responsibility of cleaning up any threads it creates, so for me the lock is fine and it is and error to call join multiple times. What do others think? On the subject of detatched threads, you have to create these youreself outside of the Boost.Threads code as far as I can see. In which case you are on your own anyway. is there a way to make detached threads portable ? I don't know enough about all the platforms to know if it is even possible to do so natively! Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |