Re: Redesigned thread class

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-29 12:35:56

From: "Peter Dimov" <pdimov_at_[hidden]>
>From: "William Kempf" <williamkempf_at_[hidden]>
>>From: "Peter Dimov" <pdimov_at_[hidden]>
>> >5. current() cannot be used to adopts threads.
>>
>>Which is simply something that users won't accept.
>
>What do you base this statement on?

Experience with other thread wrapper libraries.  Nothing that can be proved, 
at least until you make this decision and get all of the complaints, but....

>What can users do with an adopted thread?

Currently, very little (as in comparing them to other thread objects is it). 
  In the future there may be plenty, though, such as changing the thread's 
priority, possibly cancelling the thread (implementation defined), etc.

>A related question:
>
>How can I make use of thread_specific_ptr within a thread that I didn't
>create? (Adopted or Boost.Threads created.)

The current implementation has no issue with this, since the target 
implementations support TLS.  I also expect that all "native" 
implementations will support TLS, so it likely won't be an issue on any 
platform.

>If I understand the semantics of thread_specific_ptr correctly, the storage
>is never deallocated; and I can't deallocate it explicitly because I can't
>install a cleanup handler.

You understand incorrectly ;). The storage for the threads are cleaned up 
when the thread is destroyed through an implementation registered "cleanup 
handler".

Bill Kempf

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