Re: [boost] future/packaged_task Sean Parent designn

Subject: Re: [boost] future/packaged_task Sean Parent designn
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-06-24 06:48:34

On 24 Jun 2015 10:11 am, "Niall Douglas" <s_sourceforge_at_[hidden]> wrote:
>
> On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote:
>
> > Sean Parent suggests (See [1] Better Code: Concurrency) to remove the
> > promise and left the packaged_task serve as single provider of a future.
> > Both are created at once using the package factory.
>
> I was at his talk at C++ Now.
>
> The first thing which put me off his proposal was that he appears to
> be unaware of the highly optimised and very flexible de facto task
> concurrency system in C++ which has been around for years, and has
> just recently been standardised. It's called ASIO.
>
> I also think packaged_task is overkill for creating futures. There
> are some times you really do just want a promise and nothing more.

There is no reason for a packaged task implementation to be more heavy
weight than a promise. If the packaged task is [](T x) { return x; } then
it is also semantically equivalent to promise<T>, just in a nicer
interface. Bonus points it works beautifully with ASIO without any explicit
support from ASIO itself.

> There are even times you just want to create a future standalone, and
> for that we now have make_ready_future().
>
> > His future library doesn't include a shared_future as the future
> > contains a value that can be observed several times.
>
> If I remember rightly, internally his future has a shared_ptr, which
> really means he's proposing that future becomes a shared_future. I
> had doubts before until that part, but that killed his proposal for
> me. It's a non-starter as a practical design for my needs, but is
> still useful for ideas.
>

His implementation uses a shared ptr, but I think you could do without by
deep copying the futures and internally chaining via then. This way you
only pay the cost if you actually copy.

I strongly believe that 'then' and other accessors should be non const so
that concurrent calls *on the same future* need not be supported.

-- gpd