Re: Redesigned thread class

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 
Boost.Threads.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp