[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.


 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:
> 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.


 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.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:14 UTC