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

From: williamkempf_at_[hidden]
Date: 2001-06-22 09:16:04

--- In boost_at_y..., Ross Smith <ross.s_at_i...> 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.

It's a problem specificly for threads because it's very common to 
have to pass around references to other objects to allow them to 
manage the thread.  In fact the two most common idioms are to either 
create the thread and discard the reference (close the handle in 
Win32 threads or call detach() for pthreads) allowing it to manage 
itself, or to immediately pass the id/descriptor/handle/reference to 
another object(s) for management.

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

Only when the object is created on the heap.
 
> 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.)?

I mostly chose this approach to make it impossible to derive a class 
from thread (the constructor(s) are private).  This choice isn't set 
in stone yet, however.
 
> I really don't understand what problem you're seeing with this 
approach.

I've outlined the two major problems.  Greg caught one here when he 
mentions the need to create the thread objects on the heap and manage 
the raw pointers.  The other is that an object that fully represents 
the execution state instead of just referencing it should destroy 
this state in it's destructor, and this practice is very dangerous.

Bill Kempf