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 16:13:09

On 24 Jun 2015 4:30 pm, "Neil Groves" <neil_at_[hidden]> wrote:
>

Hi Neal,

long time no see..

> On 24 June 2015 at 11:48, Giovanni Piero Deretta <gpderetta_at_[hidden]>
> wrote:
>
> > 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:
>
> >
> > > 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.
> >
>
> Is there any data about this trade-off? It seems that requiring a deep
copy
> could, at least under some use-cases be substantial overhead. With a deep
> copy requirement are you prohibiting a wrapper that uses a shared_ptr? It
> seems more idiomatic to default to value-type semantics while providing
> flexibility to reduce copy/clone overhead.
>

No data yet, need to play with it a bit... Anyways, I think it might be
possible to reference count the shared_state and not pay for atomic inc and
decs as long as there is only one future. This way only if you actually
copy you pay for it.

> >
> > I strongly believe that 'then' and other accessors should be non const
so
> > that concurrent calls *on the same future* need not be supported.
> >
>
> Is this a necessary logical result of the const-ness, or do you mean you
> desire the absence of const to be able to assert misuse?

The former. Any const function is supposed to be concurrency safe, which
means that you need to protect the internal then list with a lock which I
would prefer not to do.

-- gpd