Le 26/09/13 17:46, Daniel James a écrit :

On 26 September 2013 15:49, Vicente J. Botet Escriba wrote:

...

Could I merge this fix once the regression test have cycled

Committed revision 85962. Thread: future::then should join the thread before destruction. https://svn.boost.org/trac/boost/changeset/85962 Is this a bug fix, or a standards compliance fix? If the former than yes, such fixes are fine. If the latter then I'm inclined to say yes, but another release manager might be more knowledgeable than me, or have another opinion? It is a bug fix.

Actually, I just had a look at the patch, and I don't think I understand it. Calling 'join' in the destructor for 'future_async_continuation_shared_state' seems redundant since it inherits from 'future_async_shared_state_base' and its destructor calls 'join'. Am I missing something?

Yes, here is the problem the data associated to the future_async_continuation_shared_state will be destroyed before the future_async_shared_state_base would try to join. As the thread function associated to the continuation uses these variables there is undefined behavior (a big bug :( ). Currently the regression test on clang- darwin- asan11 are failing on some the future::then tests. I hope that this change would fix them. We can anyway wait until this tester runs tomorrow. Best, Vicente

Le 26/09/13 19:37, Daniel James a écrit :

On 26 September 2013 17:05, Vicente J. Botet Escriba wrote:

...

Yes, here is the problem the data associated to the future_async_continuation_shared_state will be destroyed before the future_async_shared_state_base would try to join. As the thread function associated to the continuation uses these variables there is undefined behavior (a big bug :( ).

Currently the regression test on clang- darwin- asan11 are failing on some the future::then tests. I hope that this change would fix them. We can anyway wait until this tester runs tomorrow. Okay, I misunderstood what the change was meant to do. You didn't really need to ask since bug fixes are fine now. Sorry if I was over-fussy.

You are right. I was wrong respect to the dates. Vicente

On 9/30/2013 12:54 AM, Edward Diener wrote:

On 9/8/2013 11:18 AM, Marshall Clow wrote:

...

See the calendar at: http://www.boost.org/development/index.html

September 16: 1.55.0 Closed for new libs and breaking changes September 23: 1.55.0 Closed, except bug fixes and doc changes September 30: 1.55.0 Closed, except by permission October 7: 1.55.0 Beta release

Ping !!! I really would like to get this fix in for the 1.55 release. There is no chance the fix will affect anything in a bad way. Edward Diener

I forgot to merge the fix I made to Boost PP tuple/rem.hpp on the trunk to release. May I still do so ? It is revision 85172 on trunk. It is just a one-line addition for the macro:

#define BOOST_PP_TUPLE_REM_0()

that was missing in Boost PP.

Edward Diener

...

-- Marshall

Marshall Clow Idio Software mailto:mclow.lists@gmail.com

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 10/2/2013 11:36 AM, Eric Niebler wrote:

On 10/1/2013 5:05 PM, Edward Diener wrote:

...

On 9/30/2013 12:54 AM, Edward Diener wrote:

...

On 9/8/2013 11:18 AM, Marshall Clow wrote:

...

See the calendar at: http://www.boost.org/development/index.html

September 16: 1.55.0 Closed for new libs and breaking changes September 23: 1.55.0 Closed, except bug fixes and doc changes September 30: 1.55.0 Closed, except by permission October 7: 1.55.0 Beta release

Ping !!!

I really would like to get this fix in for the 1.55 release. There is no chance the fix will affect anything in a bad way. <snip>

Apologies. These requests are harder to spot when they're not in their own thread with a "[release]" in the subject line.

...

...

I forgot to merge the fix I made to Boost PP tuple/rem.hpp on the trunk to release. May I still do so ? It is revision 85172 on trunk. It is just a one-line addition for the macro:

#define BOOST_PP_TUPLE_REM_0()

that was missing in Boost PP.

Yes, please go ahead. If you can get it in today, great. If not, please wait until after the beta on the 7th.

Thanks ! I updated the release branch with the fix.