Michael Caisse-3 wrote
There seems to be a trend to migrate boost::thread to std::thread.
Yes, this is my inention.
Has there been consideration that perhaps the user community may not want this? There are differing opinions on threads (obviously) and recent breaking changes concern me.
For example, the thread destructor now calling terminate instead of detach has made the upgrade to 1.52 more troublesome than it should have been.
The breaking change was announced in 1.50, and it should take place on 1.53. Un Maybe I should make the announce more visible. Apologies.
Will the next move be to remove interruption points? We have purposely selected Boost.Thread on a few projects that are also using C++11 because we prefer the Boost.Thread behaviour and feature set.
The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library.
Can Vicente or someone provide the intended road map or general plan for the library?
My intention is to provide an interface that conforms to the std thread library. And build on top of this whatever is needed to respond to the user expectations. I have tried to introduce the changes letting the users to migrate to the new interface/behavior (3 releases) but it seem sthis is not the way to introduce changes :( Version 1.53 introduces these breaking changes: "Breaking changes when BOOST_THREAD_VERSION==3 (Default value since Boost 1.53): There are some new features which share the same interface but with different behavior. These breaking features are provided by default when BOOST_THREAD_VERSION is 3, but the user can however choose the version 2 behavior by defining the corresponding macro. As for the deprecated features, these broken features will be only available until boost 1.55. #6229 C++11 compliance & Breaking change: Rename the unique_future to future following the c++11. #6266 C++11 compliance & Breaking change: thread destructor should call terminate if joinable. #6269 C++11 compliance & Breaking change: thread move assignment should call terminate if joinable. " If these chages are not desired we can just set the default BOOST_THREAD_VERSION==2 and take the time to discuss of a better way to move to the direction I had in mind. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/thread-to-std-or-not-to-std-tp4640499p464... Sent from the Boost - Dev mailing list archive at Nabble.com.