Re: Boost.Threads - Final Design Decisions

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

Once again, this is true of many standard object types, including 
std::fstream.

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

(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 
>responsibility,
>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 http://explorer.msn.com/intl.asp