id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
9425,Boost promise & future does not use supplied allocator for value storage,Niall Douglas,viboes,"Presently Boost.Thread's promise and future does not use the constructor supplied allocator instance to allocate the shared state value, and instead uses operator new. This breaks with the C++11 standard behaviour.

Niall


Copy and paste from email dialogue with Vicente:

Le 20/11/13 18:07, Niall Douglas a écrit :
> Vicente,
>
> Just checking something: VS2013 is giving me a warning about unaligned
> allocation when I try to do this:
>
> 1. I have BOOST_THREAD_PROVIDES_FUTURE_CTOR_ALLOCATORS defined.
>
> 2. I initialise a promise<Int256> like this:
> boost::promise<Int256_type>(boost::allocator_arg_t(),
> aligned_allocator<Int256, 32>())
>
> 3. When I try to use set_value() on the promise, I then see the warning
> due to this function around line 551 in struct future_traits:
>
>              static void init(storage_type&
>              storage,source_reference_type t) {
>                  storage.reset(new T(t));
>              }
>
> which implies that the allocator configured for the type Int256 is not
> used because you are using operator new instead of the allocator?
>
> Maybe this is me misunderstanding how futures and promises use an
> externally supplied allocator. Your future/promise correctly uses the
> allocator to initialise shared_state, but internally to shared_state it
> then creates a scoped_ptr to hold the actual value storage and that is
> where operator new is being invoked to store the value instead of the
> allocator.
>
> If this was not intentional, can I suggest that instead of keeping a
> scoped_ptr to the value, you could instead keep the value itself stored
> in shared_state which then would have the correct alignment? You could
> use placement new and placement delete to construct/destruct the
> instance without affecting storage with a separate flag elsewhere
> indicating validity. Alternatively, I'm sure there must be some way of
> preallocating shared_state storage while the type of the custom
> allocator is still available.
>
> Thanks,
> Niall
>
Hi Niall,

you are right. I missed this allocation.

I'm too busy currently. It would be greate if you have the time to 
provide a patch.

Best,
Vicente

P.S. Please, create a ticket so that I don't forget this issue.
",Bugs,closed,Boost 1.57.0,thread,Boost 1.55.0,Problem,fixed,"promise, future, allocator",