Boost C++ Libraries: Ticket #9425: Boost promise & future does not use supplied allocator for value storage

owner, status changed

viboes — Sat, 23 Nov 2013 18:16:19 GMT

owner changed from Anthony Williams to viboes
status new → assigned

version, milestone changed

viboes — Sun, 24 Nov 2013 15:27:44 GMT

version Boost Development Trunk → Boost 1.55.0
milestone Boost 1.56.0 → To Be Determined

severity changed

viboes — Wed, 26 Feb 2014 21:37:35 GMT

severity Showstopper → Problem

Moved to problem as this doesn't prevent the use of the library.

viboes — Sun, 07 Sep 2014 17:45:36 GMT

After a first analysis, I think that we need to use unique_ptr<T> instead of scoped_ptr<T>. The problem is that we need a type erased deleter so that we can instantiate with default_delete<T> and with a specific allocator_delete<T,A>.

unique_ptr<T, erased_delete<T>>

I will start by refactoring the code, so that it is possible to set the value using an erased unique_ptr<> instead of the current source_reference_type and rvalue_source_type.

viboes — Tue, 09 Sep 2014 06:27:01 GMT

After some trials, I have fall on issues mixing the old Boost.Thread move emulation and boost::movelib_unique_ptr<T,D>, which is of course not aware of this old emulation.

I suspect that this issue could only be fixed on a version that doesn't supports the old move emulation.

I'm wondering if it will be a good idea to branch a specific future.hpp implementation that doesn't supports the old move semantics and is aligned with version 4.

Niall Douglas — Wed, 10 Sep 2014 14:41:49 GMT

FYI Vicente I have finished concurrent_unordered_map. My next task is non-allocating future-promise based on expected<T, E>, and I have been in discussions with Louis Dionne about the monadic part of the design as I do not fully understand it. Once those are complete I shall begin work.

Niall

viboes — Sun, 14 Sep 2014 12:10:04 GMT

An alternative could be to use optional<T> (waiting for expected<T>).

With optional<T> there will be no internal allocation, and so the issue will be a non-issue.

viboes — Sun, 14 Sep 2014 14:20:29 GMT

Unfortunately, optional<T> doesn't supports emulated move semantics with Boost.Move. This means that optional<T> could be used only on C++11 compilers supporting move semantics.

Niall, would this be enough for you?

milestone changed

viboes — Sun, 14 Sep 2014 19:55:09 GMT

milestone To Be Determined → Boost 1.57.0

https://github.com/boostorg/thread/commit/f73007910af7a5ef68bc5d722d262b54dd0cf3ca

Niall Douglas — Mon, 15 Sep 2014 10:48:14 GMT

To be clear, I personally no longer need allocating shared_ptr now the non-allocating future-promise is shortly to become real. My original need for allocating shared_ptr was to avoid unnecessary memory allocation, so I could recycle the buffers. That won't be necessary soon as there will be no buffers.

Also, if I am successful, I should hope the C++ 17 standard will change promise-future to match ours. And then allocation will become deprecated.

viboes — Mon, 15 Sep 2014 19:54:06 GMT

Ok. I consider then that this bug is closed.

status changed; resolution set

viboes — Tue, 23 Sep 2014 00:05:28 GMT

status assigned → closed
resolution → fixed