Boost logo

Boost :

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-20 12:01:18

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

Once again, this is true of many standard object types, including

>This forces you to introduce a "surrogate" thread
>object that is used to refer to the current thread but is not a "first
>citizen" since (1) there can be many such objects, and (2) the "primary"
>thread object may have already been destroyed.

(1) I totally don't follow this. The term "surrogate" doesn't seem to
apply, so I don't know what you mean by that. In any event, with
std::fstream "there can be many such objects" and they are "first class
citizens". I truly don't see any problem here.

(2) You are forcing the term "primary". It really doesn't matter if the
"initial" thread object is gone or not, the thread object for "current" is
still a "first class citizen".

In what way is the "current" thread object truly not a "first class
citizen"? I don't get this argument at all.

>If creating and destroying thread objects were the library's
>you could have implemented a current() function that returned a (smart)
>pointer/reference to the actual, primary, thread object.

Which would make them "second class citizens" to me. They don't represent
anything but a reference to another object, and thus are quite different
from the "primary" thread object. What you are truly advocating in all of
this is, simply, a thread::ref design... but you're using quasy terms to try
and force the design choice, and the result appears to be a poor
implementation for thread::ref.

Please, step back and try to illustrate, hopefully through code examples,
where you think there are design flaws here.

Bill Kempf

Get your FREE download of MSN Explorer at

Boost list run by bdawes at, gregod at, cpdaniel at, john at