Re: [boost] Re: Redesigned thread class

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
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.

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
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.

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.