Re: [boost] Boost.Threads - name of the "thread" type

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-22 08:05:21

Ross Smith wrote:

 >Greg Colvin wrote:
 >>
 >> If one has only the non-copyable thread object then one
 >> is tempted to traffic in raw pointers to that object, with
 >> either the usual risks of dangling pointers or else the
 >> requirement to keep the thread object around forever.
 >
 >Why do you see this as a problem specific to threads? It's exactly the
 >same for iostreams, and for that matter for anything else that's
 >non-copyable. Making objects non-copyable when the concept they
 >represent isn't naturally copyable is generally considered a _good_
 >thing by most C++ programmers.
 >
 >As for being "tempted to traffic in raw pointers", surely this is
 >exactly the sort of problem std::auto_ptr and boost::shared_ptr were
 >created to solve?
 >
 >Similarly, why have a special create() function instead of an ordinary
 >constructor, when constructors work perfectly well for every other
 >non-copyable entity (iostreams etc.)?

Thanks, Ross!  You did a better job articulating these concerns than I have 
been doing.

 >I really don't understand what problem you're seeing with this approach.

I don't either, I'm afraid.  We really need a coherent rationale - we are 
going to have to defend the design over and over again and need to be able 
to get across why the usual C++ idiom for noncopyable objects doesn't apply 
to threads.

To be blunt, it is still sounding to me like the main argument is simply 
that traditional threads programming always trafficed in handles, and so 
that approach is well understood by expert threads programmers.  But you 
could have said the same thing about FILE* at one time.  I'm awfully glad 
we moved on from there.

I expect there is more rationale than that for trafficing in thread 
handles.  But I'm just not understanding what it is, and need my mind 
expanded.  I'm trying to help Bill with documentation, and it is hard to do 
if I can't understand the rationale for a handle based approach.

--Beman