On Mar 21, 2007, at 6:01 PM, Emil Dotchevski wrote:
* The N2184::thread is non-copyable like boost::thread, but movable (taking advantage of new C++ language and std::lib features). Movable N2184::thread maintains the one-to-one mapping between the std::thread and the OS thread which boost has (sole ownership semantics). It just adds the ability to move the thread between scopes (such as return from factory functions). I recently drew the analogy this way:
boost::thread is like a scoped_ptr to the OS thread. N2184::thread is like an auto_ptr to the OS thread (the proposed unique_ptr would be a more accurate analogy).
This assumes that it is not desirable for the same N2184::thread object to be shared between multiple owners. The rationale given for the non- copyable semantics of boost::thread states that the only time you need copyable handle is in what they call "Use case 6: Creation of a thread whose ownership is shared between multiple objects", which is like saying that you only need shared handles when you need shared handles (http://www.boost.org/doc/html/threads/rationale.html#threads.rationale.non-c... doc/html/threads/rationale.html#threads.rationale.non- copyable.shared.)
I suppose similar argument can be made for movable semantics for N2184::thread, but again, what about this use case? Does N2184 argue that this use case does not exist in practice?
For this use case, N2184 argues that the use case should be supported with a higher-level library which sits non-intrusively on top of std::thread. My preferred name for this is std::shared_future (though std::tr2::shared_future is a more likely name). shared_future would be copyable, multi-joinable, and would deliver both normal and exceptional results from an asynchronous job when the shared_future is joined with. The advantage of putting this functionality in a separate class is that it costs space and time. And for clients that do not need this functionality it seems like a shame to force them to pay for it. So the big picture is to provide a series thread management objects: from low level to high level, with the lowest level being relatively small, cheap and fast, but lacking features. And the highest level adding all the niceties along with the subsequent cost. And it is hoped and anticipated that the highest level objects will end up being the most commonly used. std::thread is targeted at the very lowest level in this plan -- a solid foundation upon which much cooler stuff can be built: not only by std::lib vendors, but by anybody - portably. Peter Dimov and Ion Gaztanaga have both implemented shared ownership thread manager objects (i.e. future) on top of boost::thread (non- intrusively). I'm extremely grateful for their ground breaking proof of concept work showing that we don't need a copyable low level to support a copyable higher level. And this statement is not meant to imply that either Peter or Ion support or approve of the non-copyable (but move-only) lower level, so I feel a little guilty about stating it. But nevertheless I am grateful. And fwiw, N2184::thread delivers a std::thread which I believe has the more common motivations for a copyable std::thread: You can return it from factory functions and you can put into std::containers. These actions will only require movability, not copyability, in C++0X. -Howard