Re: [boost] Release managers: Boost.Thread breaking changes in 1.53

Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-12-30 18:39:22

Le 30/12/12 21:50, Artyom Beilis a écrit :
>> ________________________________
>> From: Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>> To: boost_at_[hidden]
>> Sent: Sunday, December 30, 2012 1:58 PM
>> Subject: [boost] Release managers: Boost.Thread breaking changes in 1.53
>>
>> Hi,
>>
>> there has been some threads about the following Boost.Thread breaking change in release 1.53.
>>
>> "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.
>>
> See, breaking API has significant cost. It seems that the distance
> between 1.53 to 1.55 is small but in practice it is huge, for long
> running project such changes may be critical, especially stuff like
> a difference between detach or std::terminate that may me "transparent"
> in the API but breaking in all other aspects.
>
> Some points:
>
>> * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] Rename the unique_future to future following the c++11.
> Is it possible to keep both future and unique_future and make them interoperable?
>
> Such that existing code would not break.
>
> If you do not must remove interface why to remove it? To make it more
> clean? Just mark it as deprecated but don't break a program that a year ago
> could be build without any problem.
I just did that. I deprecated it in version 1.50. I agree also that I 
could have both future and unique_future.
>
>> * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] Breaking change: thread destructor should call terminate if joinable.
>> * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] Breaking change: thread move assignment should call terminate if joinable.
>> "
>>
> Now I would like to know what is the rationale behind calling std::terminate instead
> of deaching the thread?
>
> Usually std::terminate is called in case no actions can be done,
> like uncatched exception is thrown.
>
> This is sort of smarter "assert()" or even I would say, we can't define the
>
> behavior, but instead of making it "undefined" lets call std::terminate.
>
> The biggest question what advatnage does it give to the user? Properly
> constructed program should not get to std::terminate, unless there is a bug,
> on the other hand some users (and I used to be one of them till I switched
> to different threading library for unrelated reasoms) expect defined behavior
> of detaching the thread...
This is exactly the reason the standard committee made these changes, 
that is, provide an interface that force the user to make correct 
programs. See 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2880.html for 
part of the rationale.
> Bottom line, what does the std library compience give us?
There will be already less confusion. See all the questions about why 
the behaviors are different in the web.
>
>> I would like to request advise from the release managers
>> and of course the Boost community. Should I rollback the
>> default to BOOST_THREAD_VERSION==3 for 1.53 and let the
>> time to discuss the best way to manage with these breaking changes?
>>
> >From my point of view if it isn't broken - don't fix it and current code
> is not.
>
> If you want std compient replcement, this is what stuff like boost::tr1 is for.
Thread is not part of tr1. Maybe we need boost::cxx11 ;-)
>
> But breaking existing code without significant reason or significant added value?
> I fail to see how it is right.
>
>
>
All depend on what do you intend by significant added value. From my POV 
the std thread was designed more carefully than Boost.Thread which was 
the implementation of one of the first proposals. The implementation was 
just frozen until the standard was fixed.

Best,
Vicente