Boost logo

Boost :

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-24 13:12:51

From: <williamkempf_at_[hidden]>
>>--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
>>So you can never "adopt" threads created outside of the library?
>For the Boost.Threads-based implementation, yes, adopting threads would be
>problematic. A possible issue that I can see is "double adoption."

The issue isn't double adoption (in fact, that's trivial to prevent). The
issue is that you don't know if an adopted thread is joinable or not. You
can't implement "join" semantics because you don't know if you can join the
thread or not (in fact, you are very unlikely to be able to). This is an
issue for both thread_ref as well as thread designs.

>>While this isn't an essential thing, users are going to find it to be
>>a major QoL issue. For instance, how can you possibly "join" the
>>main thread since this thread was not created through the library?
>I've been left with the impression that the default-constructed thread
>objects aren't joinable? Have the semantics changed again? ;-)

No. I'm talking at a much higher level than just implementing thread_ref in
terms of the current thread design. The issues that exist here are issues
that can't be easily addressed no matter what the underlying implementation
details are used for implementing thread_ref. In other words the problems
you're facing exist if you're basing thread_ref off of POSIX instead of

Bill Kempf

Get your FREE download of MSN Explorer at

Boost list run by bdawes at, gregod at, cpdaniel at, john at