Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: williamkempf_at_[hidden]
Date: 2001-07-02 10:16:35

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> > --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> 
> > > Looking back at the path the design has been taking recently, I
> > suspect
> > > we've diverged too far. I can't understand the liking so many 
people
> > > have for the "thread_ref" concept. Non-copyable objects, with 
smart
> > > pointers when necessary, are the standard C++ idiom for this 
sort of
> > > thing; why treat threads differently? I'm afraid I Just Don't 
Get
> > It.
> 
> It depends on what you are modeling, of course, but in such 
libraries
> noncopyable objects are rarely a good decision.

I disagree.

> Look at the C-style file functions, for instance:
> 
> FILE * fopen(...);
> 
> but not
> 
> void fopen(FILE * f, ...);
>
> The actual - noncopyable - 'FILE' still exists, but it's hidden. 
Users don't
> have to declare an instance of FILE, or know anything about it. 
Instead,
> they work with FILE* - an opaque handle that is freely copyable. Of 
course a
> plain FILE* requires explicit ownership tracking, but it's possible 
to
> rewrite these functions in C++ replacing a FILE* with a 
std::file_ref
> (without touching anything else) and have everything working 
exactly as it
> should, without any explicit fclose's.

In C it's not really possible to make something noncopyable.  Beman 
rightfully points out that the C++ concept for this same thing is the 
iostream, which is noncopyable.  So the assertion that such concepts 
should be copyable isn't met by your example here.
 
> If you look at existing thread libraries, you'll see the same 
pattern. The
> actual noncopyable thread 'object' is hidden deeply in the 
implementation;
> you get only a HANDLE, or a pthread_id, that is exactly a 
thread::ref minus
> the safety.

Again, this is because existing thread libraries are C libraries, 
where there's no such thing as a noncopyable type.  When modeling in 
C++ it would likely be better to stick with existing practice and 
make the C++ concept noncopyable.
 
> In this case the implementation has no choice, actually, because the
> lifetime of the hidden 'thread object' is controlled by the OS, not 
by the
> user.

Actually, it's controlled by both (thus the existance of 
pthread_detach and CloseHandle).

> > Why are Win32 handles ref-counted concepts, with DuplicateHandle?
> 
> To make C programmers' lifes easier, I guess. :-)
> 
> > _That_ is why people feel more natural with a ref-counted design.
> 
> No, not exactly. The primary motivation behind a thread::ref - 
based design
> is not that it'll use reference counting under the hood (I don't 
care
> whether it will, as soon as it implements the spec.) It's simply 
because
> lightweight copyable objects are so much easier and less error 
prone to work
> with, to say nothing about the STL.

An object such as a thread object has to either be noncopyable, be 
ref-counted (loose terminology), or rely on explicit instructions to 
release the thread state.  The noncopyable design is the typical C++ 
design.  The explicit release is the typical C design, but is error 
prone and so not the design preferred by C++ programmers.  The ref-
counted design isn't widely used and suffers from performance 
overhead issues.
 
> And, of course, not exposing the noncopyable thread prevents 
misguided
> inheritance attempts. :-)

Not much of a benefit, IMHO.

Bill Kempf