Boost logo

Boost Users :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-23 18:29:57


Caleb Epstein wrote:
> On Wed, 23 Mar 2005 20:49:02 +0200, Peter Dimov <pdimov_at_[hidden]>
> 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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net