[boost] Non-allocating future promise... Re: ASIO into the standard (was: Re: C++ committee meeting report)

Subject: [boost] Non-allocating future promise... Re: ASIO into the standard (was: Re: C++ committee meeting report)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2014-07-06 01:20:27

Niall, is your non-allocating future promise going to borrow from my C++Now
slides, or are you trying a different direction?

Tony

Sent from my portable Analytical Engine

------------------------------
*From:* "Niall Douglas" <s_sourceforge_at_[hidden]>
*To:* "boost_at_[hidden]" <boost_at_[hidden]>
*Sent:* 4 July, 2014 7:46 AM
*Subject:* Re: [boost] ASIO into the standard (was: Re: C++ committee
meeting report)

On 4 Jul 2014 at 11:46, Neil Groves wrote:

> >> I would hope Allocators would be added to ASIO in the standard. It
> >> is difficult to limit memory usage without Allocators in embedded
> >> systems.
> >
> > I hate this recurring theme of "let's take something that works well
> > today and then fsck it up by insisting it has allocator support"
>
> Since I am far less familiar with these issues than you are the solution
> to avoiding detriment to designs by having allocator support is not
> obvious to me. What should we do instead of adding allocator support?
> Should we be improving the standard allocator like the implementations
> in Boost.Container, or are you suggesting that any standardisation of
> the allocator Concept would lead to a deterioration of the design? My
> own view is that the standard allocator is clearly suboptimal even for
> standard containers. This is evident from the performance improvements
> obtained in Boost.Container. I have noticed though that the improved
> allocators do not provide superior performance on Linux systems over the
> standard implementations. ITMm very interested in your proposed solutions
> as I suspect there is much to learn from your experience working on the
> standard library implementations.

There are lots of things going on here. STL allocators were always
half baked because they were never finished - John Lakos is but one
of many who took them to all sorts of interesting new places, indeed
Stepanov's original design had enormous potential. Unfortunately,
we've ended up stuck with these half finished things, and now they
are creating slow path performance with std::vector>
because STL containers can't have a noexcept move constructor due to
allocators!

Allocators are getting patched for C++17 right now, but ultimately
the problem remains the same one as why they were never finished and
left half baked - to take them further in any direction will benefit
some uses but penalise others, so we've collectively decided that's
as good as it gets for now and left it alone: no one is seriously
proposing replacing STL allocators completely with something totally
different.

Regarding ASIO and allocators, ideally ASIO doesn't allocate nor
deallocate any memory at all during its normal course of execution,
thus removing much need for allocators and keeping latency low.
Achieving that is probably hard - just look at promise/future, in
there is an implied unavoidable malloc/free. And allocator support
for promise/future really is a mess, indeed Boost.Thread still
doesn't support that, and if I have my way it never will because
promise/future under C++11 or later is going to become malloc-free,
thereby sidestepping the problem.

Niall

-- 
ned Productions Limited Consultinghttp://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/