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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-20 08:23:19

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.

--
Peter Dimov
Multi Media Ltd.