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
>>on a thread-by-thread basis and deletes the object when a thread
>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.
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk