From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-30 11:27:59
From: "William Kempf" <williamkempf_at_[hidden]>
> 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
> 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
> 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
> 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,
> I modeled this off the documentation for std::auto_ptr where they don't
> mention of deletion when the object is destroyed. I'm not sure it's
> appropriate to reference this future event here or not.
I think that reset() is the right place to mention this, since reset() is
the only place that deals with the contained pointer.
> >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
> 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
> 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
> 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
> 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.
Something like that, yes. Seeing that you already support the functionality
anyway, I thought that it would probably be useful to expose it, especially
since it's non-trivial to implement on top of Win32.
The problem is not solved (in general) by destructors since the user doesn't
always have control over the thread procedure.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk