boost::thread noncopyability rationale

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-09 07:42:13

I've been reluctant to raise this issue for obvious reasons, but here it
goes.

The noncopyability rationale needs work. Although it is a fair, albeit
slightly colored, representation of a part of the debate, it is not really a
rationale. It reads as a rebuttal to an - unknown to the reader - article.

It is not my intent to point out inaccuracies in the text - although I can
easily identify several - but rather to help improve the section.

I suggest a wording similar to the following:

"Why doesn't boost::thread use the handle/body idiom?

During the Boost.Threads design period some Boost members expressed a
preference to a handle/body based design for boost::thread. The reasons
stated were

* The lifetime of the 'body' thread object would be managed by the
implementation; it would match closely the lifetime of the thread.

* The handle would meet the CopyConstructible, Assignable,
EqualityComparable and LessThanComparable requirements, allowing easy
integration with the Standard Library.

* The design would not require explicit memory management from the user,
eliminating a source of potential errors.

This design was rejected. Developers felt that

* The hidden lifetime management could be a source of unnecessary overhead,
and they did not want to yield manual control.

* Users can easily build their own handle/body wrapper, using for example
boost::shared_ptr.

* C++ programmers are familiar with noncopyable designs. std::fstream was
cited as an example.

* The explicit memory management is rarely required and does not cause
problems in practice."

The rationale can be expanded with real performance figures to demonstrate
the noncopyable design superiority - if deemed necessary.

--
Peter Dimov
Multi Media Ltd.