Re: [boost] future/packaged_task Sean Parent design

Subject: Re: [boost] future/packaged_task Sean Parent design
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-06-23 20:18:58

On Wed, Jun 24, 2015 at 12:09 AM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Hi,
>
> 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.
>

Yes, packaged task is a far better producer side interface than a naked promise.

I like the idea of creating the future and promise (or better,
packaged_task) together, although my preference would be a way to
create the packaged task from the future, which opens a lot of
optimiation opportunities (for example if the future is non copyable
non movable, no memory allocation is required).

> His future library doesn't include a shared_future as the future contains a
> value that can be observed several times.

This is my biggest issue with Sean's design. Sharing the state among
multiple consumes pretty much requires heavy weight synchronization.
But see below.

> The continuation takes the value and not the future.
> So a future can have
> several continuations.

What's the thread safety guarantees of future? 'As safe as int' or,
for example, concurrent calls to .then are allowed? If the former, a
copy could be a real deep copy (a new shared state is allocated and
broadcasting is internally done via 'then'). That's not how Sean
future is currently implemented though.

> If the store type is movable only, then the future
> can have only one continuation.
> Not really strange coming from Sean, future and packaged_task are copyables
> :)
> One more thing, there is not get no wait, but a get_try that return an
> optional<T>.
>

Intresting, so if  a consumer needs wait must implement it on top of
then. This is fine, but you need a way to unregister a 'then'.

> Scales better.

the interface is certanly nicer and simpler, but why do you think it
scales better?

[...]
> What are you missing ?
[...]

The when_any continuation probably needs to be passed the all the
futures instead of just the value that is ready, so that it can be
called recursively.

when_any also requires the ability to unregister a continuation from a
future, otherwise if called 'in a loop' the number of continuations
associated with futures will grow. Implementing this eficiently is not
trivial.

-- gpd