Caleb Epstein wrote:
On Wed, 23 Mar 2005 20:49:02 +0200, Peter Dimov
wrote: Ben Hutchings wrote:
This seems somewhat reasonable. However, currently there are two significantly different reasons for thread objects to be non-joinable - either the thread is default-constructed and is just an ID holder or the thread has already been joined. These should be distinguishable. I'm convinced that there should be entirely separate types for thread IDs and thread starter/joiner objects and don't understand why they were given the same type.
For various historical reasons, most of them no longer relevant. :-)
FWIW, my position on the issue has always been that all (Boost) threads should be joinable.
Even if the underlying implementation thread is not (e.g. it has been pthread_detach'd or the equivalent)? Or are you suggesting that a join on a non-implementation-joinable thread should just succeed silently?
Succeed silently, yes. That's what join means: wait for the thread to finish. If it has already finished, join should just return immediately. Not only that, it should be safe to call it from multiple threads at the same time, which should result in exactly one call to pthread_join. pthread_join is join+destructor rolled into one, but we have "real" destructors in C++, so we don't need to emulate its behavior so strictly.