[Boost-bugs] [Boost C++ Libraries] #9425: Boost promise & future does not use supplied allocator for value storage

Subject: [Boost-bugs] [Boost C++ Libraries] #9425: Boost promise & future does not use supplied allocator for value storage
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-11-22 22:47:31

#9425: Boost promise & future does not use supplied allocator for value storage
----------------------------------------+-------------------------
 Reporter:  ned14                       |      Owner:  anthonyw
     Type:  Bugs                        |     Status:  new
Milestone:  Boost 1.56.0                |  Component:  thread
  Version:  Boost Development Trunk     |   Severity:  Showstopper
 Keywords:  promise, future, allocator  |
----------------------------------------+-------------------------
 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9425>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.