Boost logo

Boost :

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
> >>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
> 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, gregod at, cpdaniel at, john at