Re: [boost] Re: Redesigned thread class

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-30 11:22:18

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.

In 20.4.5.1:

  ~auto_ptr() throw();

  Requires:
    The expression delete get() is well formed.
  Effects:
    delete get().

> I'm not sure it's 
> appropriate to reference this future event here or not.

> >BTW, you've done a great job!

Indeed!

> >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
> 
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>