Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-27 09:15:32

--- In boost_at_y..., Bill Klein <bill_at_o...> wrote:
> [About automatica detachment...]
> 
> "Greg Colvin" <gcolvin_at_u...> wrote:
> > So to do what I want I have to write
> > 
> >     thread* temp = new thread(handler);
> >     temp.detach();
> >     delete temp;
> > 
> > whereas with native code I would just do
> > 
> >     CreateThread(0,0,handler,0,0,0);
> > 
> > or in java
> > 
> >     new Thread(handler);
> 
> Actually if we went with the reference counted thread descriptor
> (my favourite name being thread_ptr that someone suggested), the
> following would do the trick:
> 
>   boost::create_thread( handler );

This is the current design, though the thread and thread_ptr types 
are merged, which lead to this whole topic.

> Because this function would return the thread_ptr, whose destructor
> would detach() (this makes perfect sense: since the last reference
> we had to the thread is gone, we can never access it anyway, so
> detach the thread and let it do its own thing). Alternatively you
> could have code such as:

Careful.  With a thread::self() method it *is* possible to obtain a 
reference to the thread even when all other references have gone 
away.  I tried to address this in the current implementation, but I 
think there may be a problem in the way I handled this.  What does 
pthreads define the behavior as if you don't detach (or join) a 
thread before the main thread of execution terminates?

>   boost::thread_ptr  thread = boost::create_thread( handler );
>   ...
>   ...
>   thread->join();
> 
> Using the reference counted smart pointer would also make thread 
pools
> and other fun things very natural.

Natural for those of us used to other threading libraries.  As 
pointed out by Beman's even asking the question, however, it's not 
necessarily natural for those very familiar with C++ design but not 
familiar with other threading libraries.

> While I'm at it, let me put in my
> vote for (as you can see above) non-member functions for anything
> that doesn't go into thread_ptr. So thread_ptr could have join() and
> detatch() and id() or whatever... And you'd have some non-members 
like
> boost::create_thread(), boost::sleep(), etc... Sticking them in a
> class seems very forced, but maybe that's just me. :)

In general this is just going to cause too many friend functions.  I 
can see an argument for sleep() and yield() (though some platform may 
make these difficult to do with out access to the internal 
implementation of the thread class), but the others you'll have a 
harder time convincing me of.

Bill Kempf