Re: [boost] Re: Boost.Threads - Final Design Decisions

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-06 12:30:20

From: Peter Dimov <pdimov_at_[hidden]>
> From: <williamkempf_at_[hidden]>
> > > Bill, I'm not trying to reopen the copyability debate. The issue is
> > > different: whether to let the user manage the lifetime of the thread
> > > objects, or to have the library take care of it. There is no hidden
> > converse
> > > meaning.
> >
> > I don't quite follow you here.  Care to elaborate?
> 
> The issue is that the current design lets users destroy thread objects at
> will, before the corresponding thread has finished. Therefore there is no
> one to one correspondence between them, that is, threads exist that have no
> associated thread object. This forces you to introduce a "surrogate" thread
> object that is used to refer to the current thread but is not a "first class
> citizen" since (1) there can be many such objects, and (2) the "primary"
> thread object may have already been destroyed.
> 
> If creating and destroying thread objects were the library's responsibility,
> you could have implemented a current() function that returned a (smart)
> pointer/reference to the actual, primary, thread object.

I always thought this was a strong argument for the thread::ref design.
As it stands it is the programmers responsibility to assure that the
thread object has a greater lifetime than any references to the thread.