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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-02 10:06:15

From: <williamkempf_at_[hidden]>

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

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.

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.

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.

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

And, of course, not exposing the noncopyable thread prevents misguided
inheritance attempts. :-)

--
Peter Dimov
Multi Media Ltd.