Re: Redesigned thread class

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-30 10:38:45

From: "Peter Dimov" <pdimov_at_[hidden]>
>From: "William Kempf" <williamkempf_at_[hidden]>
>> >I don't see this in thread_specific_ptr.html.
>>
>>Quoted from the introduction in thread_specific_ptr.html:
>>
>>"Template thread_specific_ptr stores a pointer to an object obtained via 
>>new
>>on a thread-by-thread basis and deletes the object when a thread
>>terminates."
>
>The statement makes perfect sense to me now when I already know what it's
>supposed to mean, but I somehow managed to miss its significance on the
>first - and two subsequent - readings. ;-)

Help me out then :).  I thought this was fairly clear, and there was 
supporting wording elsewhere in the document as well.  If this wasn't clear 
then how can I change the documentation to make it clear?

>The reference section doesn't mention that thread_specific_ptr calls
>'delete' on the contained pointer on thread exit, though. Only on reset>().

Where, within the reference, could I mention this?  None of the methods 
exposed in the interface deal with this event.  The fact that reset() 
requires a pointer to an object created through "new" is a strong indicator, 
but I understand that this doesn't fully cover things.  I can add the text 
in reset() indicating that the object is deleted on thread termination, but 
I modeled this off the documentation for std::auto_ptr where they don't make 
mention of deletion when the object is destroyed.  I'm not sure it's 
appropriate to reference this future event here or not.

>BTW, you've done a great job! I took a look at the implementation of
>thread_specific_ptr and was impressed. It's even possible to implement a
>cleanup handler list with it (although it'd probably be simpler to expose
>the internal cleanup handler support.)

One question and one comment.  Do you mean "cleanup handler" or "cleanup 
stack"?  They are seperate concepts in POSIX, and the "cleanup handler" is 
fully an implementation detail.  There's no need for any other type of 
cleanup handling beyond that given by the implementation.  "cleanup stacks" 
on the other hand are a fully different concept, and I don't think they're 
that useful in C++ where we have destructors that perform the same purpose.  
My comment is that the "cleanup handler" isn't fully exposed because it's 
not a type safe operation and I couldn't think of a mechanism to make it so. 
  As an implementation detail the type safety is a non-issue, since the 
implementation is gauranteed type safe.

Oh, on reflection I also suppose when you say "cleanup handler" you may mean 
a concept similar to atexit() but for threads.  I considered a 
thread::atexit(), and likely will include one in the future since it's 
trivial functionality, but I wanted to keep the interface to a minimum for 
the initial submission.

Bill Kempf

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